Magnum One/Magnum One (Mid-American Digital) (Disc Manufacturing).iso/d19/ov_msg.arc/OV.MSG

Text File | 1990-10-17 | 543.2 KB | 12,729 lines

r 1+ ns

Scanning Omniview (6)

Date: 06-06-89 (22:18)              Number: 1 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: OMNIVIEW support conf.        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Welcome to the support conference for OMNIVIEW, and greet please Dennis
Edwards, of Sunny Hill Software, who are as pleased as we of RelayNet
are at the opening of this conference in support of a great multitasking
program.

Date: 06-07-89 (21:04)              Number: 3 / 397
  To: ALL                           Refer#: NONE
From: JIM RHODES                      Read: (N/A)
Subj: HERE                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The Computer Forum BBS. Virginia Beach, Virginia is carrying this
conference.

-- Jim

Date: 06-08-89 (16:34)              Number: 4 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: WELCOME!                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Welcome to the OMNIVIEW support conference! I hope you'll find your
visits worth while.

I work for Sunny Hill as a software engineer and provide various other
technical services. I'm also new to modem mail and still feel kinda
awk-word, so if I happen to drop the ball...

What we hope to have develop here is:

- A forum for OMNIVIEW users to communicate with each other as well as
  with us. This will allow us to tap into that community knowledge we
  all sense is there but is such a bugger to track down.
- A place for potential OMNIVIEW users to get objective information
  based on your experiences.
- A medium for the exchange of information and illustrative code
  related (but not restricted) to the Applications Programmer's
  Interface to the OMNIVIEW kernal (OAPI). This has been around
  since '86 and supports C, ASM and Turbo Pascal.

As a first step toward the last objective, I've uploaded the .C and
.EXE to a simple batch file utility. The purpose of this program, which
prompts for/verifies keyboard input with time-out, is to illustrate the
differences between coding for DOS and for OMNIVIEW. The file is called
WAITKEY.ZIP (15K) and is in the BATCH directory on Rick Kunz POVERTY
ROCK board.

I would like to thank Rick for his generous help in getting this
conference up, he runs a great board and I'm glad to be here.

Thanks for stopping by.




Date: 06-08-89 (17:02)              Number: 5 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: Omniview support files        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

As an asjunct to what Dennis mentioned on the beginnings of the support
files, I'll SEND the files listed here to NETNODE, and RelayNet sysops
can request them through the network. I'm real pleased that Dennis and
Sunny Hill are doing this. It shows what great people are in the Puget
Sound region! <grin>

Date: 06-12-89 (16:38)              Number: 6 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: Omniview and BBS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

OK, I'm getting to where the 286 just might be reliable enough to put
on the BBS, and I'm looking forward to running under Omniview. I suppose
I need some general advice about pitfalls to avoid in the initial
configuration, and perhaps that'll help others who are going to the same
setup. The machine will be a VLSI chipset running at 12 MHz, and I
suppose I should pick up a copy of QEXT.SYS to convert any extended
memory (I'll have a couple megs of that). Will any other EMM driver
work? I have a LIM 3.2 board, which PC-Kwik likes pretty well, but I
think under a multitasker, 3.2 memory won't do me much good.

With the VLSI, I don't think I can strip the momboard down and backfill
(although that's something I could certainly learn more about!). Any
advice for the new setter-upper?

Date: 06-13-89 (16:15)              Number: 7 / 397 (Echo)
  To: SYSOP                         Refer#: 6
From: DENNIS EDWARDS                  Read: 06-13-89 (17:27)
Subj: Omniview and BBS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>OK, I'm getting to where the 286 just might be reliable enough to put
>on the BBS, and I'm looking forward to running under Omniview. I suppo
>I need some general advice about pitfalls to avoid in the initial
>configuration, and perhaps that'll help others who are going to the sa

On anything less than a '386, you will have to make you comm programs
non-swappable. Consequently, you will need to load as few TSR's as
possible in order to free up as much room as you can in DOS. The choice
you make in which OMNIVIEW interface you use will also makes a big
difference in the amount of space you have to use for programs.

There are two different ways of controlling OV; the first is to load
OVSHELL.COM into the first partition when you start OV (this happens by
default). OVSHELL is a menu interface that allows you to fill out a
form to describe the programs you will run, and then start and switch
between programs using "pick lists". Different menu environments can be
established for different tasks. The menu environment is established
when OV is first started by specifying a menu data file on the OMNIVIEW
command line; it can also be changed at any time from inside OVSHELL.
The shell takes up 51K of DOS memory. We include a program (XSHELL.EXE)
that will load the menu interface into LIM 3.2 (or LIM 4.0/EEMS) memory
- this takes 64K out of your EMS but only 9K out of DOS. If you look at
the menu from OVSETUP, the first method is called the standard menu
interface while the latter is referred to as expanded memory operation.

The second method uses an assortment of small utility programs that are
run from within a partition from the DOS prompt. This is called the
Expert mode of operation by OVSETUP. The OV utility programs allow you
to create and switch between programs just as the shell does: They also
allow you to send keystrokes to other partitions and perform other
functions that aren't available directly from OVSHELL. Under DOS 3.3
the smallest DOS partition that you can use to run the OV utilites is
about 32K: This is usually the answer you would give to OVSETUP when it
asks for the initial partition size.

The way to maximise your use of DOS memory is to start OV with a DOS
partition that is big enough to hold one of the comm programs: Inside
this DOS partition run a batch file that will start your other tasks
and then, after your OV environment is established, run the comm
program. Assuming the comm program allows you to shell to DOS, you can
still run the utility programs from that partition to change OV around
if you need to. The OV command line and the START.BAT file below will
start up two 200K communications programs (called COMMPGM.EXE) under
OMNIVIEW. Note that the SPAWN program creates a background process.

C\OMNIVIEW>COPY CON START.BAT
cd \COMM
\OMNIVIEW\SPAWN /M:200 /PB COMMPGM.EXE
REM: you could also spawn off other programs here, if you have room
COMMPGM.EXE
^Z

C\OMNIVIEW>OMNIVIEW /M:200 /PB \COMMAND.COM /C START.BAT

In addition to being non-swappable, comm programs should also be
set up to run in the background and to maintain their base priority in
background. Omitting the "/S" (Swappable) switch, including the "/PB"
(Priority maintained in Background) switch and NOT telling OV to
turn the program off in background accomplishes this. You can also
adjust the program's relative priority with the "/P" parameter as well the
number of "clock ticks" (55msec intervals) a program is allocated by
including the "/C" parameter. The default values (of 2 and 4 respectively)
are usually satisfactory.

If you bring down the second node for system maintenance, simply
exec to DOS from the first node and type:

C\COMM>\OMNIVIEW\OPEN /M:200 \COMMAND.COM

- screen will clear and DOS copyright notice will be displayed -

C\OMNIVIEW>SENDKEYS 1 EXIT\r

This will replace the second comm program with a 200K DOS partition.
Since OPEN is specified (vs. SPAWN) you will automatically "switch to"
that partition as soon as it is created. Using SENDKEYS to type the
"EXIT<ENTER>" string in the first partition will return to the first
comm program from its DOS shell: Note the "\r" is the 'C' language
"escape sequence" for the carriage return character - this is the
character generated by the <ENTER> (return) key.

If, instead of specifying the comm program directly in the START.BAT
SPAWN command, you could have referenced the CONTINUE.BAT file below.
In this case you would quit the second comm program in the normal
fashion and end up in DOS right away. This technique is also useful for
running TSR's inside partitions since it loads a copy of the command
processor into the partition as the batch file ends (without this the
partition would close as soon as the program "TSR'ed").

COPY CON CONTINUE.BAT
COMMPGM
%COMSPEC%
^Z






Date: 06-13-89 (16:15)              Number: 8 / 397 (Echo)
  To: SYSOP                         Refer#: 6
From: DENNIS EDWARDS                  Read: 06-13-89 (17:28)
Subj: Omniview and BBS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>suppose I should pick up a copy of QEXT.SYS to convert any extended
>memory (I'll have a couple megs of that). Will any other EMM driver
>work? I have a LIM 3.2 board, which PC-Kwik likes pretty well, but I
>think under a multitasker, 3.2 memory won't do me much good.

A general rule: except on a '386, any hardware EMS is better than an
emulator and the later the EMS software AND HARDWARE the better.

LIM refers to a specification for constructing memory cards, and
drivers for them, established by Lotus, Intel and Microsoft; the
numbers you often see associated with this acronymn describe the
version number of the spec. EEMS refers to another specification for
the same stuff called, Enhanced Expanded Memory and was developed by
AST, Quadram and Ashton-Tate. EEMS improved on LIM 3.2; LIM 4.0
includes the improvements from EEMS plus some of its own and has been
accepted by AST, Quadram and Ashton-Tate.

Since, as far as a multi-tasker is concerned, EMS emulators provide LIM
3.2 capability, lets compare them to LIM 3.2 hardware and define some
terms. Extended memory is memory above 1Meg, this is only accessible by
programs that operate in the "protected" mode of the '286 (OS/2 uses
this). The "big deal" about EMS is that specific chunks of memory that
are physically outside the 1Meg address limitation of the '286's "real"
mode (which DOS operates in) can be selectively addressed by real mode
programs. With LIM 3.2, this capability was established by creating a
special clump of "high DOS" (640K-1M) memory called the "page frame".

A page frame is a 64K block of memory, situated on a 16K boundary and
starting between paragraph (segment) addresses C000h and E000h. A
"page" is 16K bytes long and the common unit of measure for EMS memory
(again, pages physically exist somewhere other than in the lower 1M of
memory). These pages must be "mapped" into the page frame by the EMS
driver in order to be accessible to DOS applications (since they
operate in real mode and can only address 1M of memory).

A DOS program maps a page into or out of the page frame by calling the
EMS driver which flips a couple of electronic switches on the EMS
board. These switches are wired between the EMS memory chips and the
microprocessor's address lines: It is the state of these switches which
determines the "logical address" of a specific "physical" clump of
memory. The number of "mappable pages" refers to the number of pages to
which the EMS software AND HARDWARE can assign discreet logical
addresses simultaneously. The state of the switches controlling the
logical addresses of the physical EMS memory is know as the "EMS
context".

In LIM 3.2 only pages that are mapped into the page frame can be used
by DOS. Since the page frame is defined as existing above 640K, normal
DOS programs can't be loaded into it. Another problem with LIM 3.2 is
that you can only have 64K out of all the stuff that is living in EMS
be addressable at one time (since it only allows 4 mappable pages). As
a result of these limitations, when you have only LIM 3.2, extended or
disk memory to swap programs to, they won't run when they're swapped.

EMS emulators work in essentially the same way as VDISK or other
extended memory ram-disk programs. The only difference is that VDISK
wants you to think it's controlling a fast disk drive while the EMS
emulators want you to think they're controlling EMS hardware. To access
data in extended memory a program must switch the processor into
protected mode, copy the data into/out of protected memory, and then
reset the processor to return to real mode: This is a fair amount of
overhead and EMS hardware is a much quicker way to go.  Additionally,
an EMS emulator must either put the page frame inside DOS memory and
act as a 64K+ TSR or else utilize a quirk in '286 machines that allows
programs to access some memory out of the bottom of extended memory. In
either case, setting up a ram disk may be a better solution.

Two things are particularly significant about the LIM 4.0/EEMS
standards: 1) both allow EMS memory to be mapped into regions outside
of the page frame and 2) both allow for a large number of mappable
pages. Thus these standards allow chunks of EMS larger than 64K to be
moved in and out of the lower 640K at the flip of a switch, instantly
replacing one running program with another. HOWEVER, In order for this
capability to be utilized, some of the memory on the motherboard must be
disabled and replaced with memory that is physically on the EMS board:
This is called "back filling". With this done we can affect an EMS
context change and instantly exchange the running program with one that
is waiting to run in EMS. This is how you can have more programs
running at the same time than will fit into DOS. These programs will
not be able to handle interrupts at a reasonable rate, however, and
that is why communications programs must be non-swappable (except on a
'386).

Any hardware that meets the LIM 4.0 specs will have at least 64
mappable pages and these pages SHOULD be mappable in the conventional
(0-640K) memory range. For a variety of reasons, your motherboard may
not allow you to backfill; you can determine this by looking at your
hardware manual and checking the memory options it accomodates.
Appearently, a number of EMS hardware/software which claims LIM 4.0
compatability can't be mapped into conventional memory. The highest
address limit opposed by the motherboard or the EMS hardware/software
will determine the lowest EMS logical address and hence the largest
concurrent program size using LIM 4.0 on a '286 or earlier processor.

On a '386 EMS is emulated by a virtual control program and special
capabilities are provided for switching program contexts. Thus any
'386 program can live in EMS and handle interrupts in real time.


<<MESSAGE TOO LONG -- SOME LINES WERE DELETED>>

Date: 06-13-89 (18:43)              Number: 9 / 397
  To: DENNIS EDWARDS                Refer#: 7
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: Omniview and BBS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, thanks for the extensive info on startup with OV! One of the
things I appreciated was seeing the command-driven interface capability,
as well as to spawn off a program to run in the background. I've
committed your messages to paper and disk, and will be referring back to
them as I get the system ready to upgrade.

For PCBoard, one needs two partitions of about 260k. I have been working
with the EMS code which will also swap to extended memory when shelling,
so it suffers very little degradation from running in the type of config
I'm looking at. Also, I'm lucky in that I have to load virtually no
TSR's at bootup; need a couple things in config.sys, and that's about
it.

I haven't had much luck running the cache (PC-Kwik) in extended memory
under multitaskers. The combo seems to be a timebomb, and for the time
being, I'll rely on a fast HD and 1:1 interleaving, on a relatively fast
286, and performance should be pretty fair that way. However, being able
to backfill to some degree (I think the VLSI will do that, and I *know*
the NEAT board would allow it) will probably serve me best in the long
run.

I hope you don't mind some stupid questions along the way! It's a great
opportunity to draw on your expertise, and I appreciate the chance to do
it right "the first time"!

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 06-14-89 (17:23)              Number: 10 / 397 (Echo)
  To: SYSOP                         Refer#: 9
From: DENNIS EDWARDS                  Read: 06-14-89 (19:39)
Subj: PC-KWIK                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I haven't had much luck running the cache (PC-Kwik) in extended memory
>under multitaskers. The combo seems to be a timebomb, and for the time

Have you tried the "/N+" switch when you install the cache?

This is an undocumented command line parameter which, according to the
PC-Kwik tech support folks, tells to cache "to not make as many
assumptions about the environment". It is supposed to allow operation
in multi-tasking environments and has worked in other installations.






Date: 06-14-89 (17:23)              Number: 11 / 397 (Echo)
  To: SYSOP                         Refer#: 9
From: DENNIS EDWARDS                  Read: 06-14-89 (19:40)
Subj: BACK-FILLING EMS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>286, and performance should be pretty fair that way. However, being ab
>to backfill to some degree (I think the VLSI will do that, and I *know
>the NEAT board would allow it) will probably serve me best in the long
>run.

Back-filling will only help with LIM 4.0/EEMS hardware. If you have LIM
3.2 memory hardware you're still limited by the number of page mapping
registers that can be used to define an EMS context- and all four of
these will be used in the page frame.

As far as removing RAM from the board: My understanding is that the
configuration switches/jumpers that are set on the mother-board
determine whether or not a given memory read/write is passed to the
expansion but or not. If the mother-board offers a "low mother-board
memory" setup then you should be able to count on the fact that the
VLSI isn't going to get in the way. The top of motherboard memory will
determine the BASE address of the EMS.

It is also possible to "top-fill" to the bottom of the video adapter.
If your setup allows this you can have an extra 64K with a mono adapter
and an extra 94K with a CGA.



>I hope you don't mind some stupid questions along the way! It's a grea
>opportunity to draw on your expertise, and I appreciate the chance to
>it right "the first time"!

Nonsense, ain't no stupid questions.  Hope it works.




Date: 06-14-89 (19:40)              Number: 12 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: 10
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: PC-KWIK                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Since I saw the /N+ mentioned in the OV manual, I have been using that
one on the test system, but have been avoiding running the cache when
multitasking that system.  That one has the NEAT chipset, but I haven't
been able to devote the time to really getting that system configured
right, and it isn't set up properly to take advantage of all the
capabilities of the NEAT set.  I loaded NEATEMM.SYS just today, and was
told it wasn't configured properly, so the Extended memory wasn't
converted.  The manual leaves a little bit to the imagination when it
comes to EMM configuration!

It's a nice board for someone who likes to tweak things. Addonics 16
MHz 286, only two megs onboard now, but all kinds of configuration
options.  I'm hedging a little until I can observe what happens fully,
since I have munged the FAT several times on the test systems,
generally under <shudder> DoubleDos..  I also have avoided putting the
LIM 3.2 board in that box until I fully understand just how it should
work with the onboard hardware.  It will take up to 8 megs onboard,
configurable in almost any config (except I don't think I can tell the
chipset to strip the momboard below 512k). The NEAT set probably will
allow anything an addon board would, with that motherboard, anyway.
The software is there -- just gonna take time! <grin>

Date: 06-15-89 (12:08)              Number: 13 / 397 (Echo)
  To: SYSOP                         Refer#: 12
From: DENNIS EDWARDS                  Read: 06-15-89 (17:18)
Subj: PC-KWIK                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Since I saw the /N+ mentioned in the OV manual, I have been using that
>one on the test system, but have been avoiding running the cache when
>multitasking that system.  That one has the NEAT chipset, but I haven'
...
>options.  I'm hedging a little until I can observe what happens fully,
>since I have munged the FAT several times on the test systems,
>generally under <shudder> DoubleDos..  I also have avoided putting the

Blown FATs are what forced the discovery of the "/N+" switch.




Date: 06-15-89 (12:08)              Number: 14 / 397 (Echo)
  To: SYSOP                         Refer#: 12
From: DENNIS EDWARDS                  Read: 06-15-89 (17:19)
Subj: NEAT CHIP SET                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>capabilities of the NEAT set.  I loaded NEATEMM.SYS just today, and wa
>capabilit>told it wasn't configured properly, so the Extended memory wasn't
>converted.  The manual leaves a little bit to the imagination when it
...
>configurable in almost any config (except I don't think I can tell the
>chipset to strip the momboard below 512k). The NEAT set probably will
>allow anything an addon board would, with that motherboard, anyway.

I don't have any docs on this hardware - but from what you say it
appears to provide some true EMS capability on the mother board. This
changes the approach you want to take a little bit:

Try to convert the conventional (0-640K) memory to EMS: If you can do
that then you've essentially back-filled. You still won't be able to
handle interrupts in EMS but you can run other kinds of programs
concurrently within the backfilled space. If the docs/setup menu talk
about a "starting EMS memory location" and only give addresses between
C0000h and E0000h absolute then they're talking about where to put the
page frame and are not describing this capability.

If you can back-fill this way then also look for a way to set the
number of Alternate Page Mapping Registers Sets (AMRS). This will
determine the number of independent EMS contexts the EMM driver can keep
track of and the EMM driver can track this information more efficiently
than an application. The number of AMRSs that you will want to allocate
is equal to: (max number of active processes - 1)

You also want to try to set up a 48K block of contiguous memory outside
of the page frame (typically between D4000h-E0000h absolute with the
page frame starting at E0000h absolute). This is usually called
"including" EMS memory. If your equipment allows this then you can run
OMNIHIGH in place of OMNIVIEW. OMNIHIGH.COM is a program on the OV disk
that loads OMNIVIEW.EXE into the included EMS and reduces the total OV
overhead (in DOS) to as little as 10K. Be sure NOT to "include" any
memory regions that already belong to a ROM.

If you can specify "includes" and are running MDA/CGA, see if can set
up a second "include" between the top of your RAM and the bottom your
video. This "top-fill" will give you a bunch more room for running
programs.

If you can't back-fill or "include" then, effectively, you're memory is
LIM 3.2. You can only use it as a sort of fast swapping disk - but
you'll save a slot by not having to install an EMS board.









Date: 06-15-89 (21:14)              Number: 15 / 397
  To: DENNIS EDWARDS                Refer#: 14
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: NEAT CHIP SET                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Well, the NEAT's hardware is definitely LIM 4.0 compatible, but the
ability to backfill with it leaves something to be desired. I was able
to convert a meg of extended memory to expanded (only have two megs
onboard now); I know this worked 'cause I was able to jam a meg of
PC-Kwik into 19k of DOS memory, and at least we've gotten that far, so
I could at least run a 325k partition and have 170k left for a second
partition, running DDos at this time.  (Yeah, I know...). This is a
pretty standard config on this test system. If I were running PCBoard on
it, the bottom partition would be about 230k instead of 170.

No matter what I've tried so far, OMNIHIGH won't run, so apparently I'm
not able to backfill properly, at least not with the config as I have
it.  I think I can reclaim a few k of DOS memory, though, by reducing
buffers if the cache will run reliably, so there's progress!  There's a
lot more tweaking to do with the NEAT config.  It should allow memory
to be moved about anywhere (except perhaps below 640k).  There is an
option to tell it the RAM between 512 and 640 is on an i/o channel, so
it's possible I could page in there, though I haven't gotten that to
work as yet.  Probably understandable, since there's no addon board in
there.

I appreciate your good advice so far! Will keep you posted.

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 06-14-89 (23:49)              Number: 18 / 397
  To: ALL                           Refer#: NONE
From: WILLIAM PARFITT                 Read: (N/A)
Subj: NOW RELAYING                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

HUBSD/dBored San Diego Public Information Service now Relaying here. WP

Date: 06-18-89 (08:34)              Number: 19 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: Initial messages              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Since many of you may not have gotten in on the original intros, etc,
I'm re-relaying the early messages in this conference back out. Welcome
to all!

Date: 06-18-89 (09:26)              Number: 33 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: Expanded mem conversion       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Well, using PC-Kwik with the memory converted to expanded has its own
quirks. I'm getting lockups in the bottom partition (of DD, not OV) when
I run Vern Buerg's LIST in that partition -- getting a "Can't load
COMMAND" halt when exiting the listed file. This is some quirk of LIST,
I think, because  most everything else I use runs fine, including
editors, games, etc. I suspect it'd be the same with OV or whatever
multitasker..

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 06-23-89 (12:02)              Number: 34 / 397
  To: ALL                           Refer#: NONE
From: STEPHEN THURBER                 Read: (N/A)
Subj: OV command line               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

when running Omniview using the command line interface what switch
setting should be used to keep a task from running in the background.
ie:
OPEN /M:256 /S PROG.EXE
what would be added to the above to run only in foreground for PROG?

PCRelay:RUNNINGA -> RelayNet (tm)
                    The Running Board * 301 229-5342 * MD

Date: 06-23-89 (12:06)              Number: 35 / 397
  To: ALL                           Refer#: NONE
From: STEPHEN THURBER                 Read: (N/A)
Subj: GEM under OMNIVIEW            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

anyoneout there have any experience running a GEM application under
Omniview?
I have tried Publish It but found the screen destroyed when i switch the
partition to backgound then back to foreground.
I am using the /V switch, display is Sigma Designs EGA 480 with an
analog monitor (VGA B&W).
DTK 286 hardware with 640k and no TSRs.

PCRelay:RUNNINGA -> RelayNet (tm)
                    The Running Board * 301 229-5342 * MD

Date: 06-24-89 (23:25)              Number: 36 / 397
  To: ALL                           Refer#: NONE
From: MARK ADKINS                     Read: (N/A)
Subj: On line                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The Omniview conference is On Line in Oregon.


Date: 06-26-89 (15:27)              Number: 37 / 397
  To: ALL                           Refer#: NONE
From: PHIL DAVIES                     Read: (N/A)
Subj: Hello                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Gonzo BBS (HUBOHIO) now supporting this conference....

PCRelay:GONZO -> RelayNet (tm)
                 GoNzO <HUBOHIO> 614-239-6474 HST's ->239-6475

Date: 06-27-89 (06:58)              Number: 38 / 397 (Echo)
  To: STEPHEN THURBER               Refer#: 34
From: DENNIS EDWARDS                  Read: NO
Subj: OV command line               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>when running Omniview using the command line interface what switch
>setting should be used to keep a task from running in the background.
>ie:
>OPEN /M:256 /S PROG.EXE
>what would be added to the above to run only in foreground for PROG?

There are really two issues: foreground and visibility. A foreground
process is, by definition, the one attached to the physical keyboard
(the program you can type into). On system with a single display
controller there is only one visible process and that process is also
foreground. On a dual monitor system you can have two programs that can
be run on seperate displays, each of them will be "visible" on their
own display and one will also be foreground. Limiting operation to
either foreground or visible status is done by adding arguments to
different OMNIVIEW devises when you create the partition.

To limit a process to foreground operation, tell the keyboard device
that the program reads the keyboard directly:

D>OPEN /M:256 /S     /D:KBD:D      PROG.EXE

To limit a process to visible operation, tell the screen device that
the program has to have its own screen:

D>OPEN /M:256 /S     /D:SCR:FGO    PROG.EXE




Date: 06-27-89 (06:58)              Number: 39 / 397 (Echo)
  To: STEPHEN THURBER               Refer#: 35
From: DENNIS EDWARDS                  Read: NO
Subj: GEM under OMNIVIEW            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>anyoneout there have any experience running a GEM application under
>Omniview?

Are you allocating a virtual graphics screen? It takes more
memory to store graphics screens than text screens and OMNIVIEW won't
allocate a graphics screen unless you tell it to. Odd colored hash
marks in the top of the display are often the result of running a
graphics program with a text "screen".  From the command line this would
be accomplished using:

/D:SCR:CGA    - CGA resolution
/D:SCR:EGA    - standard EGA resolution (32K buffer)
/D:SCR:EGB    - standard VGA/enhanced EGA resolution (64K buffer).





Date: 06-28-89 (18:30)              Number: 40 / 397
  To: ALL                           Refer#: NONE
From: DAVE HILL                       Read: (N/A)
Subj: OMNIVIEW & LANTASTIC          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I am running a two node (two machines) PC Board system using Lantastic.
I understand that if I want to add a third node to my 286 machine it is
possible to use Omniview to multitask.  Can anyone tell me if it is
possible to do this and what command line entries I would need to make
to allocate at least 250K to each partition?

PCRelay:BYPASS -> RelayNet (tm)
                  Springfield Bypass (703)-941-5815  USR-HST

Date: 06-29-89 (03:16)              Number: 41 / 397
  To: DENNIS EDWARDS                Refer#: 39
From: STEPHEN THURBER                 Read: 12-06-89 (11:28)
Subj: GEM under OMNIVIEW            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

if i use /D:SCR:EGB the buffer apparently takes enough memory that there
is not enough left to run publish-it.  i wonder if i would regain enough
by using an EMS board and xshell to be able to have the buffer and run
publish-it.
interestingly, publishers paintbrush still gets its screen destroyed (in
the upper part of the screen) even with /V and /D:SCR:EGB.  screen
recieves exactly the same damage with or without /D:SCR:EGB.  i can't
figure it out.

PCRelay:RUNNINGA -> RelayNet (tm)
                    The Running Board * 301 229-5342 * MD

Date: 06-29-89 (21:12)              Number: 42 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: COPY FROM PRODOOR CONF.       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Taking the liberty to copy this msg from the ProDoor (Sam Smith) support
conference since I don't think you're taking it and it does concern OV.

>Date: 06-26-89 (17:02)     TOOLSUPP Number: 3275
>  To: BILL WALSH
>From: SAMUEL SMITH                    Read: NO
>Subj: AN OLD PROBLEM REVISITED
>
>BW>Sam, I seem to recall a problem with ProDoor and Omniview (Taskview)
>BW>testing uploads during the ARC days.  I have recently experienced sy
>BW>hangs and abnormal terminations at the point that ProDoor tests uplo
>BW>.ZIP files.  Do you recall what the workaround for that problem was?
>
>Yes, the work around was to go to a non-Katz ARC tester.  It seems that
>Katz continues to use the routines that are incompatible with Omniview.
>As a kluge-around you might change the PKUNZIP -T to actually unzip the
>files into a scratch directory, then delete them afterwards.  Only
>problem is that you will start collecting all the hidden members in
>tested uploads.
>
> ;; Sam

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 07-02-89 (23:38)              Number: 43 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: HOANG PHAM                      Read: 12-06-89 (11:28)
Subj: LIM 4.0                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> Any hardware that meets the LIM 4.0 specs will have at least 64
> mappable pages and these pages SHOULD be mappable in the conventional
> (0-640K) memory range.

Dennis, I have a 12-MHz AT momboard of relatively recent design that
uses the SunTac chipset and has a (supposed) EMS 4.0 driver.  Memory is
set for 640K conventional and 1408K expanded.  Page size & number is 16K
x 88 respectively (the latter could be increased to 216 given another 2
meg add-on).  EMS port address can be set for either 0E8-0EFh or
098-09Fh.  Since the pages can be map into conventional memory and it is
in excess of 64 pages, does this qualify the board for EMS 4.0 operation
with respect to the multitaskers, or is there any other qualification?
Also, does this take care of the "backfill" problem, and eliminate any
need for an EMS 4.0 board?

One other question, my primary machine right now is a 386 using Win386.
Does Omniview have an extended memory manager to be used with a 386?
Thanks for any insight you can give.

--H.P.

Date: 07-03-89 (07:07)              Number: 44 / 397 (Echo)
  To: DAVE HILL                     Refer#: 40
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW & LANTASTIC          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I understand that if I want to add a third node to my 286 machine it i
>possible to use Omniview to multitask.  Can anyone tell me if it is
>possible to do this and what command line entries I would need to make
>to allocate at least 250K to each partition?

It is being done.

Ideally, you would have an EMS 4.0 board that allows you to allocate
blocks of memory in the 640-1M ("high DOS") memory range so that you can run
OMNIHIGH: This program will load OV into this "high DOS" EMS region and
save several K of RAM in the lower 640K. If you don't have such a board
you will need about 550K free before running OV in order to get two
550K partitions.

My initial messages in this conference talked about setting up BBS
partitions. To summarize, bring up the network before running OMNIVIEW
then perform the following steps:

C\OV\>COPY CON STARTUP.BAT
CD\PATH
C:\OV\SPAWN /M:250 /PB PROGRAM.EXE
PROGRAM.EXE
^Z

C:\OV\>OMNI????  /M:250 /PB  \command.com /c startup.bat

The OMNIVIEW or OMNIHIGH command will start up OV with a batch file
running in the first partition. The batch file will create a second
partition with the BBS running in it and then load a second copy of the
BBS in the first partition. Re-using the first partition will maximise
the amount of memory that you have for each partition but will require
that you "shell out" to DOS and use the command line utilities to
control OV.











Date: 07-03-89 (10:59)              Number: 45 / 397 (Echo)
  To: HOANG PHAM                    Refer#: 43
From: DENNIS EDWARDS                  Read: 07-04-89 (02:34)
Subj: LIM 4.0                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>meg add-on).  EMS port address can be set for either 0E8-0EFh or
>098-09Fh.  Since the pages can be map into conventional memory and it

These I/O ports are used by the EMM and have no direct effect on a
multi-tasker. Other hardware may rely one of these I/O regions being
available and that is why they are selectable.

>set for 640K conventional and 1408K expanded.  Page size & number is 1
>x 88 respectively (the latter could be increased to 216 given another
>...
>098-09Fh.  Since the pages can be map into conventional memory and it
>in excess of 64 pages, does this qualify the board for EMS 4.0 operati
>with respect to the multitaskers, or is there any other qualification?
>Also, does this take care of the "backfill" problem, and eliminate any
>need for an EMS 4.0 board?

What it sounds like you should be able to do is to remove some (the
more the better) of the 640K of conventional memory and then map EMS
into the space that was opened up in the lower 640K. This "Backfilling"
eliminates the address conflict between the physical conventional
memory and those physical EMS memory chips that are logically mapped
into the conventional memory space. The motherboard hardware and/or
firmware will require a minimum amount of conventional memory to be
resident on the motherboard to avoid errors in the the BIOS
Pre-Operational System Tests (POST): The minimimum amount of memory
allowed by the motherboard will determine the maximum amount of EMS
that can mapped into the conventional memory space.

As it stands now, the EMM can control 16K/page*88pages=1408K of EMS: If
you can map 512K of this into the lower 640K (backfill) and then load a
512K process, you will have 896K of EMS left over to hold additional
processes and satisfy the needs of your applications. Most LIM 4.0
drivers supplied with plug in boards will allocate memory in the lower
640K when they're loaded and your software should offer this option (or
do it automatically) so that the RAM is available to DOS and
applications programs.

You should also try running OMNIHIGH which will attempt to allocate 48K
of EMS memory in the 640K-1M ("high DOS") address space and load the OV
kernal into this EMS region. This would leave 848K of EMS in your
system.

If you can successfully perform both the backfill and high-DOS
allocation operations then OV should work well with your motherboard.

>One other question, my primary machine right now is a 386 using Win386
>Does Omniview have an extended memory manager to be used with a 386?

We recommend 386^MAX by Qualitas (Bethesda, MD). The "professional
version" of this product can also load device drivers into high memory
(assuming you have room and need to do so). Sunny Hill discounts both
of these products.





Date: 07-03-89 (10:59)              Number: 48 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: NEW SUNNY HILL MAILING AD     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Please note that the mailing address in the front of the OMNIVIEW
manual is incorrect.  All correspondence should be directed to:

Sunny Hill Software
PO Box 55278
Seattle, WA 98155-5278

Sorry for any inconvenience, the manual is being updated.




Date: 07-03-89 (15:52)              Number: 50 / 397 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: RICK KUNZ                       Read: 07-03-89 (16:25)
Subj: TEST MSG                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

->POVTEST

test

Date: 07-04-89 (04:11)              Number: 52 / 397
  To: ALL                           Refer#: NONE
From: MICHAEL QUINLAN                 Read: (N/A)
Subj: BOISE, IDAHO                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The Greater Boise BBS in Boise, Idaho is now relaying the OMNIVIEW
conference.

                              --- Michael Quinlan ---

PCRelay:BOISE -> RelayNet (TM)
                 Greater Boise BBS*Boise ID*208-322-5227 HST

Date: 07-05-89 (03:42)              Number: 53 / 397
  To: DENNIS EDWARDS                Refer#: 44
From: DAVE HILL                       Read: 12-06-89 (11:28)
Subj: OMNIVIEW & LANTASTIC          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks for the reply on running a multinode BBS with Omniview.  I joined
the conference late so I missed your original message.  I am also
missing the board in my AT machine that will create expanded memory.
When I loaded Omniview originally I couldn't see how I could get enough
lower memory to run two nodes.  Now I know the answer.  Thanks again!

PCRelay:BYPASS -> RelayNet (tm)
                  Springfield Bypass (703)-941-5815  USR-HST

Date: 07-06-89 (11:41)              Number: 54 / 397 (Echo)
  To: DAVE HILL                     Refer#: 53
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW & LANTASTIC          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Thanks for the reply on running a multinode BBS with Omniview.  I join
>the conference late so I missed your original message.  I am also

Do you think a text file on EMS usage by multitaskers in general is
something that would be a useful thing to put on "the net"?. Any other
topics you might want to see?.





Date: 07-06-89 (10:02)              Number: 55 / 397
  To: ALL                           Refer#: NONE
From: PHIL MARCELLO                   Read: (N/A)
Subj: PCBoard                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have a problem running PCBoard in the Background with Omniview.
I am using Lantastic, Server and 386MAX.

I create a 300K window. The node runs fine in the foreground
but in the background, the modem anmswers and PCBoard just counts
down to zero and reboots.

Any ideas.

PCRelay:DATACOMM -> RelayNet (TM)
                    Data Comm - Rochester N.Y. 716-328-3844

Date: 07-07-89 (11:51)              Number: 56 / 397 (Echo)
  To: PHIL MARCELLO                 Refer#: 55
From: DENNIS EDWARDS                  Read: NO
Subj: PCBoard                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I create a 300K window. The node runs fine in the foreground
>but in the background, the modem anmswers and PCBoard just counts
>down to zero and reboots.

It sounds like the PIC/UART ISR is being reset. If you're running an OV
version < 4.13 then let me know: An upgrade will almost certainly solve
the problem. You can prove that this is the problem by loading a TSR
that simply returns from the IRQ (or buffers the data) prior to loading
OMNIVIEW: it should keep the background node running (though data
over-runs will occure during context switches).



Date: 07-07-89 (12:26)              Number: 57 / 397 (Echo)
  To: PHIL MARCELLO                 Refer#: 55
From: DENNIS EDWARDS                  Read: NO
Subj: PCBoard                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I create a 300K window. The node runs fine in the foreground
>but in the background, the modem anmswers and PCBoard just counts
>down to zero and reboots.

It sounds like the PIC/UART ISR is being reset. If you're running an O
version < 4.13 then let me know: An upgrade will almost certainly solv
the problem. You can prove that this is the problem by loading a TSR
that simply returns from the IRQ (or buffers the data) prior to loadin
OMNIVIEW: it should keep the background node running (though data
over-runs will occure during context switches).



Date: 07-08-89 (05:20)              Number: 58 / 397
  To: ALL                           Refer#: NONE
From: HOWARD BELASCO                  Read: (N/A)
Subj: 386/server                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have been told that to use my 386 as a server I would have to give
up DV. But to use the 386 as a workstation, I could not access the other
drives in the network. What I want to do is this, LAN my 386 with an AT
and an XT.  I have 2 nodes on the 386 using DV.  I have 4 megs of
memory. I want to keep the multitasking ability on the 386 as I have
many business files there, but I also want to keep at least one BBS node
there and add one BBS node to each of the other machines,
giving me a total of 3 nodes .Someone has suggested that I run the AT
with OMNIVIEW and put 2 nodes there and then run the 386 with
OMNIVIEW and then I could run the 386 as a server and still access the
other drives and still maintain multitasking.All this under a LANTASTIC
network. Does this make sense? Is it doable?

PCRelay:RUNNINGB -> RelayNet (TM)
                    The Running Board * 212-654-1349 * HST

Date: 07-07-89 (23:10)              Number: 59 / 397
  To: DENNIS EDWARDS                Refer#: 56
From: PHIL MARCELLO                   Read: 12-06-89 (11:28)
Subj: PCBoard                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>It sounds like the PIC/UART ISR is being reset. If you're running an OV
>version < 4.13 then let me know: An upgrade will almost certainly solve

I am running 4.13, is there a newer version ???

PCRelay:DATACOMM -> RelayNet (TM)
                    Data Comm - Rochester N.Y. 716-328-3844

Date: 07-09-89 (04:10)              Number: 60 / 397
  To: DENNIS EDWARDS                Refer#: 54
From: DAVE HILL                       Read: 12-06-89 (11:28)
Subj: OMNIVIEW & LANTASTIC          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>Do you think a text file on EMS usage by multitaskers in general is
DE>something that would be a useful thing to put on "the net"?. Any other
DE>topics you might want to see?.

I think it would be helpful.  In my opinion, Sunny Hill needs to get the
word out to sysops that they have a fine multitasking product that is
very compatible with PC Board and I assume other BBS software.  The way
I found out about your Omniveiw was by reading, so to speak, in between
the lines in various messages on Salt Air and through word of mouth.

I first head about Taskview (didn't know about the name change to
Omniview once again except for a message on Salt Air) about three years
ago.  A sysop in the local area had experienced a great deal of
difficulty running DoubleDos and subsequently switched to Taskview.  He
swore by your product and recommended it to anyone who was looking for a
stable software product to run two BBS nodes on one machine.  For
whatever reason, your company doesn't advertise in many of the magazines
(or if you do then I am missing the ads).  Maybe this conference will
help.

The reason I bought Omniview was also due to a message on Salt Air from
a sysop who has four nodes runnning under Lantastic on two machines.  My
board is expanding.  I now have two nodes and two AT class machines and
before long I expect to be putting up a third node.  The most economical
way to do this is to use Omniview and multitask.  However, I need 250K
of the lower 640K of RAM to do this (Your last message explained how I
could go about obtaining this RAM).  There are a lot of PC Board sysops
who are switching to Lantastic.  Thus, for those who want to put up a
third node, as far as I know you currently offer the only way to do this
without going out and buying another computer.

PCRelay:BYPASS -> RelayNet (tm)
                  Springfield Bypass (703)-941-5815  USR-HST

Date: 07-10-89 (15:08)              Number: 61 / 397 (Echo)
  To: STEPHEN THURBER               Refer#: 41
From: DENNIS EDWARDS                  Read: NO
Subj: GEM under OMNIVIEW            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>if i use /D:SCR:EGB the buffer apparently takes enough memory that there
>is not enough left to run publish-it.  i wonder if i would regain enough
>by using an EMS board and xshell to be able to have the buffer and run
>publish-it.
>interestingly, publishers paintbrush still gets its screen destroyed (in
>the upper part of the screen) even with /V and /D:SCR:EGB.  screen
>recieves exactly the same damage with or without /D:SCR:EGB.  i can't
>figure it out.


With EMS in the system, OMNIVIEW will automatically allocate a buffer to
hold the current display buffer outside of the partition.  If you specify a
buffer size or have no EMS, the buffer is taken up in the partition and
leaves less room for the program to operate.  XSHELL is designed to be used
on LIM 3.2, though it can be a benefit if you can't backfill with EMS. It
takes 64K of EMS plus 9K of DOS memory.

I am confused as to the kind of "screen damage" you are experiencing.  I
have tried to call but only have an appearently old work number on file.
If you could contact me by voice it would help.  Does the damage have
anything to do with the mouse position?  Does the picture remain intact but
the colors change. Is the picture completely destroyed.  Have you tried a
different (lower resolution/less color) video driver (like one for an IBM
EGA)?




Date: 07-11-89 (11:10)              Number: 63 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: Direct video writes           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

A common tech support question is "How can a programmer detect the presence
of OMNIVIEW and control direct screen writes without relying on the API".

Using the BIOS int 10h extensions introduced with TopView will work with
most multitaskers including OMNIVIEW.  To enable OMNIVIEW's support for
these functions you must answer 'Yes' to the question "Supports TopView
Functions" in the OVSHELL program form or else add the "/T" switch to the
OPEN/SPAWN command line when the creating the partition.

When your program starts up, Set ES:DI to the text buffer of the monitor
you want to use ($B800:0000 for color, $B000:0000 for mono), set AH to $FE
and call int 10h. If the same values are returned in ES:DI then no
multitasker is installed; otherwise, the virtual screen base address is
returned.

Turbo Pascal's CRT unit and the Turbo C conio routines write directly to
video memory by default, you can use the result of the comparison between
the passed and returned ES:DI values to set the value of the "directvideo"
boolean variable -- this forces BIOS writes under a multitasker when it's
value is FALSE (0).

When using other video routines under OMNIVIEW, writing to the virtual
video buffer after a int $10 fn $FE call results in automatic updating of
the virtual screen so BIOS video calls and direct video writes to the
returned buffer address may be freely intermixed in foreground or
background. No int 10h fn $FF calls are required.

Date: 07-20-89 (07:54)              Number: 65 / 397
  To: ALL                           Refer#: NONE
From: HOWARD BELASCO                  Read: (N/A)
Subj: TEST                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

This is a test message from Thursday.

PCRelay:RUNNINGB -> RelayNet (TM)
                    The Running Board * 212-654-1349 * HST

Date: 07-20-89 (20:44)              Number: 66 / 397
  To: ALL                           Refer#: NONE
From: RUSSELL MANGEL                  Read: (N/A)
Subj: NE                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Welcome All!
    The Hocus Pocus PCBoard is now Relaying this Conference, located
in Plentywood Montana, 4406-765-1451 running PCBoard 14.1/E3 with
Prodoor, and the Qmail door! Free access to all!
    Your Sysop is Russell Mangel
1200 to 38,400 Baud (USRobotics HST/1440) 24hrs/7days) zoooom!!!
Hocus Pocus BBS, (406)-765-1451


PCRelay:HOCUS -> RelayNet (tm)
                 Hocus Pocus PCBoard HST 1440 406-765-1451 Mt

Date: 07-20-89 (19:20)              Number: 67 / 397
  To: HOWARD BELASCO                Refer#: 65
From: RICK KUNZ                       Read: NO
Subj: TEST                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>This is a test message from Thursday.

Received here Thursday evening. At least it's working! Now we gotta get
the thread from SYSOPS going in here!

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 07-21-89 (19:46)              Number: 68 / 397
  To: ALL                           Refer#: NONE
From: MICHAEL QUINLAN                 Read: (N/A)
Subj: OMNIVIEW VS DESQVIEW          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I run a PCBoard-based BBS and will someday go to multiple nodes. I have
been acting on the assumption that my options were Desqview or
Lantastic. I hadn't considered Omniview because I don't think I had
ever heard of it (though its previous name, Taskview, does ring a bell).

I would like to run a 3-node BBS on a single 10Mhz AT. One of the lines
will be 9600, the other 2400. The third node will just be for local use
(via the console) and won't have a modem.

Is it reasonable to use Omniview in this configuration?

How would Omniview be better than Desqview in this configuration?

How much memory will it take?

What sort of compatibility problems will I run into? I use PC DOS 3.3,
Ontrack Disk Manager and one CDC SWIFT 200 meg 3.5" disk drive with ESDI
interface. The disk has two partitions (one 32meg, the other 150meg),
the second partition uses a 4K sector size, 34 sectors/track (cluster
size is 16k). I also have a Hitachi CD-ROM drive and controller and
run MS DOS Extensions 2.0.

Thank you.

                              --- Michael Quinlan ---

PCRelay:BOISE -> RelayNet (TM)
                 Greater Boise BBS*Boise ID*208-322-5227 HST

Date: 07-20-89 (06:08)              Number: 69 / 397
  To: RICK KUNZ                     Refer#: NONE
From: JOHN TYLER                      Read: 07-22-89 (08:35)
Subj: THIS CONFERENCE               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Rick, PWRCOM is carrying this conference. Although I haven't had a
message here in over a week.

John

PCRelay:POWERCOM -> RelayNet (TM)
                    Palm Harbor, Fl - 2 HST Nodes - [phone]

Date: 07-22-89 (07:46)              Number: 70 / 397
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: Omniview Conference           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks to all who responded; I hope the distribution problems which seem
to have been plaguing this conference are solved and we'll see the
traffic in here which it warrants! Welcome to all nodes, new and old.

Dennis Edwards, of Sunny Hill Software is conference host here, and
perhaps Dennis will take a moment to introduce himself and OV once
again, so that those who missed the original posts will get updated.
OV is a great product and the company is sensitive and appreciative
toward Sysops -- and *I* can relate to that!

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 07-23-89 (19:23)              Number: 71 / 397
  To: ALL                           Refer#: NONE
From: BOB HUNTER                      Read: (N/A)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I, for one, just started taking this conference like. Curious to learn
more about Omniview. Currently am running DV on a 386 and would be
interested in what this product is capable of.

An overview for us new folks would be nice!

PCRelay:CHEMEK -> RelayNet (TM)
                  Chemeketa OnLine [phone] Salem, OR

Date: 07-25-89 (10:12)              Number: 72 / 397 (Echo)
  To: MICHAEL QUINLAN               Refer#: 68
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW VS DESQVIEW          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I run a PCBoard-based BBS and will someday go to multiple nodes. I have
>been acting on the assumption that my options were Desqview or
>Lantastic. I hadn't considered Omniview because I don't think I had
>ever heard of it (though its previous name, Taskview, does ring a bell).
>
>I would like to run a 3-node BBS on a single 10Mhz AT. One of the lines
>will be 9600, the other 2400. The third node will just be for local use
>(via the console) and won't have a modem.
>
>Is it reasonable to use Omniview in this configuration?

On a single AT you should be able to run two nodes, three will probably not
fly: The reason for this is that you will probably not get them all to fit
in the TPA and EMS context changes on less than a '386 machine aren't quick
enough to ensure real time interrupt handling by processes outside of the
TPA.  If you could afford to replace one of the modem nodes with the local
node (by swapping the former out) then OV alone would meet your needs.

If you were to run this same setup on a '386 with a VCP like 386^MAX, then
all three nodes would be able to operate simultaneously.  A second
alternative is to install Lantastic and a second AT or XT class machine to
handle one or two outside nodes. Since, to my knowledge, PCBoard currently
only supports COM1 and COM2; you are limited to two modem nodes per
machine.  The last OV process to revector an IRQ owns it: loading two nodes
on the same COM port will cause the first to be left in the cold.

>How would Omniview be better than Desqview in this configuration?
>How much memory will it take?

One of the major differences between OV and DV is that all OV processes are
full screen.  This means that OV is smaller and runs quicker: When running
high speed modems, particularly under a network, this is an important
consideration.

With LIM 4.0 hardware or virtual LIM 4.0 on a '386, the space you have to
run programs can actually grow by loading OV if you have a CGA or MDA
display adapter.  With an EGA/VGA system and the same type of expanded
memory, OV requires between 10-30K in DOS when OMNIHIGH is run to load the
kernal into EMS memory.  If the kernal must be loaded into conventional
memory it takes 48K.  The optional menu interface takes 51K of conventional
or LIM 4.0 memory or 9K of conventional and 64K of LIM 3.2 memory.  The
smallest partition size for a DOS "control" process is about 32K w/ DOS
3.3.  To get the most out of BBS machine without EMS, create one partition
of the size needed by the BBS that runs a batch file to open a second
similar partition and then load the first BBS in the inital partition after
the second is created.

If you program, you may find the OV Application Programmer's Interface (for
ASM, C and Turbo Pascal) to be of interest. This is free, upon request, to
OV users.

>What sort of compatibility problems will I run into?

I know of no problems with any of the hard/sofware you mentioned. You will
find that OV works quite well with the vast majority of programs.

Date: 07-25-89 (10:12)              Number: 73 / 397 (Echo)
  To: RUSSELL MANGEL                Refer#: 66
From: DENNIS EDWARDS                  Read: NO
Subj: NE                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>    The Hocus Pocus PCBoard is now Relaying this Conference, located

Welcome!


Date: 07-25-89 (10:12)              Number: 74 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: Welcome to OV conference      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Welcome to the OMNIVIEW support conference! I hope you'll find your
visits worth while. I work for Sunny Hill as a software engineer and
provide various other technical services. What we hope to have develop here
is:

- A forum for OMNIVIEW users to communicate with each other as well as
  with us. This will allow us to tap into that community knowledge we
  all sense is there but is such a bugger to track down.
- A place for potential OMNIVIEW users to get objective information
  based on your experiences.
- A medium for the exchange of information and illustrative code
  related (but not restricted) to the Applications Programmer's
  Interface to the OMNIVIEW kernal (OAPI). This has been around
  since '86 and supports C, ASM and Turbo Pascal.

As a first step toward the last objective, I've uploaded the .C and
.EXE to a simple batch file utility. The purpose of this program, which
prompts for/verifies keyboard input with time-out, is to illustrate the
differences between coding for DOS and for OMNIVIEW. The file is called
WAITKEY.ZIP (15K) and is in the BATCH directory on Rick Kunz POVERTY
ROCK board. This file has been SENT to NETNODE and your boards sysop can
request it through the network.

I am also in the process of preparing a text file that will contain
discussion of the some of the common questions asked here so far, as well
as the answers to common questions asked on the Tech Support line.  This
file will be uploaded as soon as it is completed (sometime this week). I
will leave messages letting you all know of its availability/updating.

Thanks for stopping by.

Date: 07-25-89 (10:12)              Number: 75 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: omniload.bat error msgs       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The inscrutable "Omniview dismounted from memory." message is a source of
frustration to users who are new to the command line interface. I have
uploaded a file named OMNILOAD.ZIP to Poverty Rock. This batch file will
print out an error message in response to OV's exit code.


Date: 07-25-89 (12:50)              Number: 76 / 397 (Echo)
  To: BOB HUNTER                    Refer#: 71
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I, for one, just started taking this conference...
>An overview for us new folks would be nice!

OMNIVIEW (formerly TASKVIEW) is a preemptive multitasker for DOS programs;
this differentiates it from Microsoft Windows, Software Carousel and others
which do not provide true multitasking. You CAN achieve true multitasking
with Microsoft windows by running multiple Windows '286 applications inside
of OMNIVEW.

Unlike Quartedeck's DESQView, each OMNIVIEW process is a full screen
application - this makes OMNIVIEW both smaller and faster; A very important
consideration when running concurrent real time applications (such as high
speed communication programs or industrial control systems) or when relying
on memory hungry device drivers and TSRs. Any TopView/DESQView aware
application will run as expected.

In contrast to VM/386, OMNIVIEW does not utilize (nor impose the overhead
of) the '386 virtual 8086 mode. Each process operates in real mode.

The increasingly popular "dos extenders" may be fully utilized inside any
OMNIVIEW partion, allowing multiple concurrent multi-megabyte applications.
While OMNIVIEW is compatible with Quarterdeck's QEMM and other virtual
control programs, we recommend Qualitas' 386^MAX ($49.95) to get the
maximum benefit of OMNIVIEW and your '386 system; the professional version
of this program ($100) will also load device drivers into high memory,
maximizing the space available to run other programs.

SysOps quilify for a 35% discount off OMNIVIEW's $79.95 retail price.

OMNIVIEW's features include:

-- As many as ten concurrently operating programs on a single machine.
-- Runs on all PCs from 8088 to 80386 based systems.
-- True multitasking with user specifieable time slice duration (127
   levels) and relative process priorities (15 levels).
-- Utilizes LIM 3.2, 4.0 and EEMS memory.
-- TSR's loaded before OMNIVIEW can be accessed by all processes.
-- TSR's loaded inside partitions act just as any other program, to
   remove them just kill the partition.
-- Supports all standard video adapters in all modes.
-- Loads in as little as 10K of conventional memory.
-- INCREASES memory available to run DOS applications by over 80K on some
   systems.
-- Keyboard macros and the ability to "cut and paste" among applications.
-- Easy to use menu interface.
-- Command line interface with a powerful collection of utility programs
   allows experienced users maximum flexibility.
-- Free technical support and much more.

The OMNIVIEW Application Programmer's Interface (OAPI), available for the
asking, has supported C, ASM and Turbo Pascal programmers since 1986.
All OAPI applications have the ability to:

-- Create and eliminate sibling processes.
-- Suspend, activate and control sibling processes.
-- Send keystrokes to programs running in other partitions.
-- Send and receive various message objects.
-- Perform time sequenced, background events.
-- Establish shared data areas.
-- Create "invisible" customized user interfaces to integrated multitasking
   applications.
-- and much, much more.


Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

Orders:    [phone]
Technical: [phone]



Date: 07-25-89 (17:25)              Number: 77 / 397
  To: DENNIS EDWARDS                Refer#: 76
From: BONNIE ANTHONY                  Read: 12-06-89 (11:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, can you use QEMM to manage your memory or do you need to use 386
to the max?

PCRelay:RUNNINGA -> RelayNet (tm)
                    The Running Board * 301 229-5342 * MD

Date: 07-22-89 (22:28)              Number: 78 / 397
  To: MICHAEL QUINLAN               Refer#: 68
From: PHIL MARCELLO                   Read: NO
Subj: OMNIVIEW VS DESQVIEW          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I would like to run a 3-node BBS on a single 10Mhz AT. One of the lines
>will be 9600, the other 2400. The third node will just be for local use

Just remember, the current version of PCBoard only supports
COM1 and COM2

PCRelay:DATACOMM -> RelayNet (TM)
                    Data Comm - Rochester N.Y. 716-328-3844

Date: 07-25-89 (15:46)              Number: 79 / 397
  To: DENNIS EDWARDS                Refer#: 75
From: HOWARD BELASCO                  Read: 12-06-89 (11:28)
Subj: OMNILOAD.BAT ERROR MSGS       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, I have ordereed OV and will be asking you zillions of questions.
Could you please check with Rick to see if he cansend your files to the
netnode for requesting by us poor folks out here in relay land?

Thanks!

PCRelay:RUNNINGB -> RelayNet (TM)
                    The Running Board * 212-654-1349 * HST

Date: 07-26-89 (09:03)              Number: 81 / 397
  To: HOWARD BELASCO                Refer#: 79
From: RICK KUNZ                       Read: NO
Subj: OMNILOAD.BAT ERROR MSGS       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  To: DENNIS EDWARDS                Refer#: 71

>Could you please check with Rick to see if he cansend your files to the
>netnode for requesting by us poor folks out here in relay land?

The Omniview files Dennis sends up are already on the nethub, Howard. If
you see it announced here, it should be requestable from NETNODE in
short order. Bonnie even made me feel guilty enough that I'm putting SDI
descriptions in 'em! :-)

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 07-26-89 (17:54)              Number: 82 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: OV Application Notes          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


The Application Notes have been posted on Poverty Rock in OV_NOTES.ZIP
(32745 bytes).  The archive includes:

ADVERT.TXT      An advertisement describing features of OMNIVIEW.
                Includes options for contacting Sunny Hill.

COMMANDS.TXT    Explains the correspondence between the basic
                options of the menu system program form and the
                command line interface. Information on options
                not discussed in this document may be found in
                SCHEDULE.TXT, TOPVIEW.TXT and INTERUPT.TXT

COMPROGS.TXT    A discussion of the issues involved in running
                "high speed communications" programs on systems
                with 80286 and earlier microprocessors. This
                document will also be of interest to people
                wanting to maximise memory or run other types of
                programs in the background.

MEMORY.TXT      Explains the various kinds of memory available
                and how they are used (and not used) by
                multitaskers in general.  Includes specifics on
                OMNIVIEW.

INTERUPT.TXT    Describes how interrupts are handled by OMNIVIEW.

SCHEDULE.TXT    Describes how to determine when an OMNIVIEW process
        will run.

TOPVIEW.TXT     Discusses OMNIVIEW's TopView(TM) emulation and
                its use of virtual screens.

VISIBLE.TXT     A discussion of visiblity, foreground and
                OMNIVIEW's dual monitor support.


I hope you find these worthwhile. Feel free to forward any feedback you may
have.


Date: 07-26-89 (19:27)              Number: 83 / 397 (Echo)
  To: BONNIE ANTHONY                Refer#: 77
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Dennis, can you use QEMM to manage your memory or do you need to use 386
>to the max?

Hi, Bonnie.
OMNIVIEW will work with QEMM but works little better with 386^MAX since
some of the QEMM features that DV uses are not documented; the virtual
screen stuff for example. The major stuff like expanded memory and the like
work OK.

If you have a lot of .SYS files to load, 386^MAX prof. can put them up high
if there's room.

Date: 07-26-89 (19:27)              Number: 84 / 397 (Echo)
  To: HOWARD BELASCO                Refer#: 79
From: DENNIS EDWARDS                  Read: NO
Subj: OMNILOAD.BAT ERROR MSGS       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Could you please check with Rick to see if he cansend your files to the
>netnode for requesting by us poor folks out here in relay land?

done.

Date: 07-26-89 (13:30)              Number: 86 / 397
  To: DENNIS EDWARDS                Refer#: 73
From: RUSSELL MANGEL                  Read: 12-06-89 (11:28)
Subj: NE                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis,
   Nice to get a Welcome from you, I have gotten my self in trouble with
a bunch of the conferences, I guess they don't like New Boards
advertising that they are now carrying, such and such conference,
(apparantly looked like a BBS add), I got some nastly letters, fr

PCRelay:HOCUS -> RelayNet (tm)
                 Hocus Pocus PCBoard HST 1440 406-765-1451 Mt

Date: 07-27-89 (00:41)              Number: 87 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: 82
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: OV Application Notes          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>The Application Notes have been posted on Poverty Rock in OV_NOTES.ZIP
>(32745 bytes).

       On its way to NETNODE tonight, too.

Date: 07-25-89 (04:21)              Number: 89 / 397
  To: ALL                           Refer#: NONE
From: KEITH LUKEN                     Read: (N/A)
Subj: OMNIVIEW/386-MAX              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I purchased OMNIVIEW 4.10 several months ago and have been playing with
it off and on trying to get it setup to run my 2 node BBS, problem I
have is according to their info I should be getting windows as big as
those I get with QEMM/DESQVIEW, I have tried using QEMM and 386-MAX,
both yield similar results! They recommend 386-MAX, but do not tell you
the command line entries they recommand with it!  I have set 386-MAX up
a few different way and still no luck, my biggest windows are in the
upper 300K range (350-400)! I can get 512K windows with DESQVIEW! Can
someone that has 386-MAX allowing them large windows show me what ther
config.sys and Autoexec.bat look like??? Thanks!

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 07-26-89 (19:36)              Number: 90 / 397
  To: RICK KUNZ                     Refer#: 81
From: HOWARD BELASCO                  Read: 07-27-89 (10:02)
Subj: OMNILOAD.BAT ERROR MSGS       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Good show!

BTW, is there anypone out there that is running PCBoard with OV? Would
sure like ot have a setup form somewhere to use as a guide. Hate like
Heck to be a pioneer.

PCRelay:RUNNINGB -> RelayNet (TM)
                    The Running Board * 212-654-1349 * HST

Date: 07-27-89 (17:30)              Number: 91 / 397
  To: DENNIS EDWARDS                Refer#: 83
From: BONNIE ANTHONY                  Read: 12-06-89 (11:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have ordered omniview and the 386 to the max professional and hope ;to
tinker with it starting next week.

Can you write linked scripts to bring up both nodes of pcboard at the
same time?

Could you post a typical setup for a node of pcboard so we could have a
starting place?

PCRelay:RUNNINGA -> RelayNet (tm)
                    The Running Board * 301 229-5342 * MD

Date: 07-26-89 (20:53)              Number: 92 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: PCB with OMNIVIEW             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis,
 I purchased OMNIVIEW several months ago and gave it only a quick glance
when I received it, I tinkered with it on several occassions because I
have heard that is runs faster and more effeicent than DV. I have
386-MAX and have been told by your people that I should get comparable
partition sizes to QEMM/DV. I run a PS/2 80 (20Mhz with 12 Meg RAM). I
have OV 4.1 and when running 386-MAX and OV I only get partition sizes
in the under 400K range, under QEMM/DV I get 512K per partition. I was
wondering if you could help me with the following few questions-
1- What is proper 386-MAX setup to fully utilize OV on my system
2- Since my OV is a few months old and 4.1 is it still current?
3- I run two 19200 nodes of PCB 14.2 how will OV compare to my present
   QEMM/DV setup as far as speed ( will it handle the 2 modems)
4- How should I best setup OV to allow my 2 nodes to run at their
   max effeicency reliably.
5- I have been told that DV can't run on a file server and OV can, if
   this is true can you tell me how well it would run on a file server
   and how it would be impacted and any restrictions that may apply?

Thanks for hearing me out, I am extremely interested in OV and bought it
after several GOOD reviews in PC WEEK and PC MAG  which indicated OV
might have the edge over DV in thruput!

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 07-28-89 (19:24)              Number: 93 / 397
  To: BONNIE ANTHONY                Refer#: NONE
From: KEITH LUKEN                     Read: NO
Subj: OV                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I see we seem to have common curiousity in OV, I have had it for a while
and been a little lazy because the first time I tried playing with it I
only got in upper 300K range per window, but I must have had 386MAX
setup wrong and probably OV also! My ultimate goal it to be able to run
OV on my PS/2 80 as a file server to my PS/2 55 so I don't have to keep
moving disks back and forth! I'm also hoping can handle my two 19200
nodes as well as DV/QEMM does! I here OV is more effiecent with CPU
power than DV is...

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 07-30-89 (10:27)              Number: 94 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 89
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW/386-MAX              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I purchased OMNIVIEW 4.10 several months ago and have been playing with

You can get an upgrade to 4.13 by calling in and requesting it. Reference
this message.

>someone that has 386-MAX allowing them large windows show me what ther
>config.sys and Autoexec.bat look like??? Thanks!

COPY CON CONFIG.SYS
DEVICE = 386MAX INCLUDE=D400-E000 AMRS=9 [other parms] SCREEN

COPY CON OV.BAT
OMNIHIGH /S [other parms] ovshell.com programs


OV_NOTES.ZIP, available on the network, is a collection of application
notes you may find of value.  OMNILOAD.ZIP is a batch file that can
either be used in place of OV.BAT or called from it - it contains error
messages related to OMNIVIEW.EXE (OMNIHIGH) exit codes.



Date: 07-30-89 (10:27)              Number: 95 / 397 (Echo)
  To: HOWARD BELASCO                Refer#: 90
From: DENNIS EDWARDS                  Read: NO
Subj: OMNILOAD.BAT ERROR MSGS       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>BTW, is there anypone out there that is running PCBoard with OV? Would
>sure like ot have a setup form somewhere to use as a guide. Hate like

The size of the partitions you will need depend on the memory
requirements of the doors you will run; otherwise, the setup for all
communications programs is essentially the same (ICA is required since its
written in BASIC).

OPEN /PB /D:SCR:NOWAIT;ICA;EMS D:\PATH\PROGNAME.EXT [parameters]

ON A '386 add the /S parameter to the front of the open parameters.


Date: 07-30-89 (10:27)              Number: 96 / 397 (Echo)
  To: BONNIE ANTHONY                Refer#: 91
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Can you write linked scripts to bring up both nodes of pcboard at the
>same time?

Currently, OV doesn't offer its own script language.  The OAPI includes a
sample program to do this OR you can use a batch file that runs in the
first partition.

>Could you post a typical setup for a node of pcboard so we could have a
>starting place?

The memory required for a given PCBoard partition will depend on the
memory needed to support you doors.

D:\>COPY CON CONFIG.SYS
DEVICE = 386MAX INCLUDE=D400-E000 AMRS=9 [other parms] SCREEN
^Z

D:\OMNIVIEW>COPY CON D:\OMNIVIEW\LOADEMUP.BAT
D:
CD PATH
SPAWN /s /pb /m:KKK /d:scr:nowait;ems;ica PROGNAME.EXT [parameters]
...
[open up other partitions you may need here]
...
PROGNAME.EXT [parameters]
^Z

D:\OMNIVIEW>OMNIHIGH /s /pb /m:KKK /d:scr:nowait;ems;ica
D:\COMMAND.COM /c LOADEMUP.BAT

You may also find OV_NOTES.ZIP, a collection of Application Notes available
on the network, of value; also pick up OMNILOAD.ZIP is a batch file that
provides error messages according to the exit codes from OMNIVIEW.EXE
(which is loaded into the D400-E000 EMS block (created by the 386MAX
include statement) when OMNIHIGH is executed).







Date: 07-30-89 (10:27)              Number: 97 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 92
From: DENNIS EDWARDS                  Read: NO
Subj: PCB with OMNIVIEW             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>1- What is proper 386-MAX setup to fully utilize OV on my system

To fully utilize OV you would need to allocate a 48K EMS block in the "high
DOS" region, unfortunately, IBM'S "advanced BIOS" takes up an extra 64K in
this memory region and 386MAX no longer allows short (<64K) page frames:
This leaves only 32K so, unless you can do without a page frame, you can't
load OV high.  Loading OV high saves 20-40K in the TPA. You should use
XBIOS.SYS (see the 386MAX readme file), set AMRS=9 and include SCREEN as
the last parameter on the command line.

>2- Since my OV is a few months old and 4.1 is it still current?

4.13 is the current version, call in for an upgrade and reference this
message.

>3- I run two 19200 nodes of PCB 14.2 how will OV compare to my present
>   QEMM/DV setup as far as speed ( will it handle the 2 modems)

OV only requires that each program responding to hardware interrupts has
its own unique IRQ; this means that you can only run two nodes of PCBOARD
per machine in its current flavor. OV handles about 100000 IRQ signalled
context switches per second on a 20MHz '386. A 19200bps comm port
generates about 2500 IRQ's/second. The execution time of the IRQ handler
is, of course, variable.

>4- How should I best setup OV to allow my 2 nodes to run at their
>   max effeicency reliably.

The memory requirements for a given PCBoard application depends on the
needs of the doors you will be running; aside from this, the only thing
different from PCBoard and something like ProComm is that the ICA device be
included on the command line (since it's written in BASIC). The general
form for all communications programs run on a '386 is to make them
swappable, maintain their background priorities and insure that neither FGO
nor direct keyboard utilization is specified on the command line:

D>OPEN /s /m:KKK /pb /d:scr:nowait;ems;ica D:\PATH\PROGNAME.EXE [parms]

You may wish to pick up OV_NOTES.ZIP and OMNILOAD.ZIP off the network: The
former is a collection of Application Notes and the latter is a batch file
that includes error messages in response to OMNIVIEW.EXE'S exit codes.

>5- I have been told that DV can't run on a file server and OV can, if
>   this is true can you tell me how well it would run on a file server
>   and how it would be impacted and any restrictions that may apply?

Using LANTASTIC, there are no special requirements.

Date: 07-30-89 (12:59)              Number: 98 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have been experimenting since I left you my previous note and have
some curious problems I need your assistance on,...
I have 386MAX 4.04 running on my PS/2 80 - 20 MHZ with the following in
my config.sys -
device=c:\386max\XBIOS.SYS
DEVICE=C:\386MAX\386MAX.SYS INCLUDE=B000-B7FF screen
DEVICE=C:\$FDD5.SYS (driver for IBM external 5.25 disk)
device=C:\386MAX\386DISK.SYS 2048 512 128 /EMS
device=C:\386MAX\386DISK.SYS 2048 512 128 /EMS
device=C:\386MAX\386DISK.SYS 2048 512 128 /EMS
device=c:\dos\ansi.sys
break=on
files=96
buffers=8
SHELL=C:\DOS\COMMAND.COM /P /E:2048

I have tried to use OMNIHIGH but it says it coild not allocate EMS I
figure OV needs some minimum that I can't provide, 386MAX says a I have
56KB of high ram and can use 42KB block..
I start OV using OV.BAT and then have 2  selections on MENU for my 2
nodes of PCB, both are set for no swapping to disk, HIGH SPEED COM is
yesy and BASE PRIORITY I tried 15,8, 6 and 4 all with same results, also
I tried clock ticks at 4,3 and 2 again no difference. I have lower
PRIORITY in background to NO! I have tried with NO additional EMS
available set and with 32Meg available! I tried YES and NO for writes
directly to SCREEN and also tried TEXT and GRAPHICS for display type!
All ways showed exactly same results- first I had only 396KB per window
only ( I get over 512K with QEMM/DV, even with my 8514 card), and when I
open the second node it just loops with modem reset errors and
eventually locks up OV since CTRL-ALT-DEL won't work and the only way to
get out of this is by powering off system! The problem is exactly same
no matter which node I open first, the second PCB partition to start
always loops like that regardles which actual COM port node it is!
HELP!!! HELP!!! HELP!!! THanks!!!!!!!!!!!!

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 08-01-89 (14:10)              Number: 99 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 98
From: DENNIS EDWARDS                  Read: NO
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I have 386MAX 4.04 running on my PS/2 80 - 20 MHZ with the following in
>my config.sys -
>device=c:\386max\XBIOS.SYS
>DEVICE=C:\386MAX\386MAX.SYS INCLUDE=B000-B7FF screen

You should also set AMRS=9. As for the stated INCLUDE, see below...

>I have tried to use OMNIHIGH but it says it coild not allocate EMS I
>figure OV needs some minimum that I can't provide, 386MAX says a I have
>56KB of high ram and can use 42KB block..

In order to allocate EMS for OMNIHIGH w/ 386^MAX you have to tell MAX to
emulate 48K of _contiguous_ EMS in the "high DOS" region above the display
adapter's memory. 48K = C00h paragraphs and you don't have this much. As it
stands you have allocated 32K of EMS inside your VGA. Here is a map of the
model 80's memory:

┌──────────────────────────┐ 10000h (1Meg)
│ Normal BIOS & ROM BASIC  │
├──────────────────────────┤ F000h - all PCs, XTs, ATs and PS/2s
│ Advanced BIOS            │
├──────────────────────────┤ E000h - PS/2s Model 50+
│ Page Frame               │
├──────────────────────────┤ D000h - MAX won't use less than 64K
├──────────────────────────┤ C800h - from here to D000h is free (32K)
├──────────────────────────┤ C000h - VGA BIOS (32K)
├──────────────────────────┤ B800h - Color Text display memory (32K)
│                          │
│                          │
├──────────────────────────┤ A000h (640k) - EGA/VGA graphics memory (96K)
│                          │ 0-640K is "low DOS" memory

Without incuring some sort of conflict, you won't be able to use OMNIHIGH
on an "Advanced BIOS" machine; your largest partition size should be
about 60K less than what is available after you boot your machine.

>buffers=8

Unless you're using a disk cache, you should set "BUFFERS = 30" (see pg
2-10 in the User's Manual).

>I start OV using OV.BAT and then have 2  selections on MENU for my 2

Run OVSETUP and select "standard menu operation" and then select "save
changes and exit".  Restart OMNIVIEW with this BAT file.

>nodes of PCB, both are set for no swapping to disk, HIGH SPEED COM is
>yes...

For any program on a '386, select the following options:

Can Swap to Disk:         YES
    With LIM 4.0 memory programs won't actually swap "to disk" but
    rather will be paged in and out of the EMS memory pool.

Display Type:            TEXT
    OMNIVIEW allocates EMS memory for the virtual display buffer
    automatically, the size of the display buffer depends on the video
    mode when the program is switche out of foreground

Maximum Expanded Memory:    Minimum required by the program.
    Some programs will eat up all of the EMS, leaving none for other
    processes.

Required Memory:        Minimum required by the program.
    If this is too low, DOS will flash up a not enough memory to load
    program" message in the upper left hand corner of the display.

Desired Memory:            Maximum you want to give it.
    Specifying more than is available will always give the largest
    partition available.

For any COM program on a '386, select the following options:

Runs in Background:        YES
Lower Background Priority:     NO

High Speed Communications:    NO
    This is a short cut designed to aid users with systems based on
    '286 and earlier CPU's. It simply changes other program form
    options to elimnate swapping to disk, to maintain the background
    priority and to enable running in the background.

You may also increase the priority and clock ticks for COM programs but
this will further impact the responsiveness of other programs when they are
foreground and usually won't be neccesary. Program Title, Startup Command
amd Startup Directory vary with the program being defined; all other
options may be left at their default.

Date: 07-31-89 (17:37)              Number: 100 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: LOADEMUP.BAT                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>^Z
>
>D:\OMNIVIEW>COPY CON D:\OMNIVIEW\LOADEMUP.BAT
>D:
>CD PATH
>SPAWN /s /pb /m:KKK /d:scr:nowait;ems;ica PROGNAME.EXT [parameters]
>...
>[open up other partitions you may need here]
>...
>PROGNAME.EXT [parameters]
>^Z
>
>D:\OMNIVIEW>OMNIHIGH /s /pb /m:KKK /d:scr:nowait;ems;ica
>D:\COMMAND.COM /c LOADEMUP.BAT
>

Dennis, in the above example I saw you recommend I have some questions,
first I assume that the last 2 lines are actually starting a DOS window
that would remain resident,thus using precious clock cycles? I could
remedy that by making last line of LOADEMUP.BAT be the EXIT command I
assume? That should leave just the other windows up, correct? Now when
partitions are loaded this way I assume that the OVSHELL menu is not
loaded? Correct? Does that then mean that I can not open any additional
partitions without shutting down the first 2 and reloading OV? Also the
ICA option which is required for BASIC programs, how does one invoke
that from the setup parameters when configuring partitions thru the
menu? I am still having alot of problems setting up my 2 nodes, I
finally seem to have them to run, but I get some strange results, when I
signed on to local node the user on the 1st node started getting garbage
characters and PCB aborted with a FATAL ERROR, the ANSI characters were
screwed up in the loacl node like it was dropping interrupts, any ideas?
I have added the AMRS=9 option to my config.sys which fixed the second
node just looping with MODEM RESET ERRORS. I also notice that while both
nodes of PCB are up, I can't get the MENU to come back by hitting
CTRL-1( I have reassigned the key seq with ovsetup) it just displays the
top of screen, but not the menu... thanks again! I must say that you
have been responsive to everyones questions and very pateint, I am glad
you and your company value this channel of support/promotion of your
product! QUARTERDECK has long been on my TOP 5 list of companies I love
to hate, their support is one of the worst I have seen! I have been
looking for a long time to DUMP QEMM/DV and OV finally is becoming a
realistic alternative, especially since I can run it on a SERVER!!

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 08-02-89 (16:07)              Number: 102 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 100
From: DENNIS EDWARDS                  Read: NO
Subj: LOADEMUP.BAT                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>>D:\OMNIVIEW>COPY CON D:\OMNIVIEW\LOADEMUP.BAT
>>D:
>>CD PATH
>>SPAWN /s /pb /m:KKK /d:scr:nowait;ems;ica PROGNAME.EXT [parameters]
>>...
>>[open up other partitions you may need here]
>>...
>>PROGNAME.EXT [parameters]
>>^Z
>>
>>D:\OMNIVIEW>OMNIHIGH /s /pb /m:KKK /d:scr:nowait;ems;ica
>>D:\COMMAND.COM /c LOADEMUP.BAT
>
>Dennis, in the above example I saw you recommend I have some questions,
>first I assume that the last 2 lines are actually starting a DOS window
>that would remain resident,thus using precious clock cycles? I could
>remedy that by making last line of LOADEMUP.BAT be the EXIT command I
>assume? That should leave just the other windows up, correct?

The "^Z" represents the end of the LOADEMUP.BAT file.  The last two lines
represent a single command to start up OV with a DOS partition (that is big
enough to hold the first node) running a batch file.  The last line of the
batch file loads the first node into the first partition after spawning off
the second. Two partitions would exist at this time, both of them running a
copy of the same program.

>Now when
>partitions are loaded this way I assume that the OVSHELL menu is not
>loaded? Correct?

Yes.

>Does that then mean that I can not open any additional
>partitions without shutting down the first 2 and reloading OV?

No. You could shell out to DOS (from one of the nodes) and the use the
command line utils (SPAWN or OPEN) to create subsequent partitions.
Alternatively, you could spawn off two partitions in the batch file and
then load the shell into the first partition to automate the startup: The
first partition would be about 51K in this case.  The problem with loading
the shell on anything less than a '386 is that the non-swappable COM
programs will block it from being used.

>Also the
>ICA option which is required for BASIC programs, how does one invoke
>that from the setup parameters when configuring partitions thru the
>menu?

ICA is a default device parameter in the shell.

>I am still having alot of problems setting up my 2 nodes, I
>finally seem to have them to run, but I get some strange results, when I
>signed on to local node the user on the 1st node started getting garbage
>characters and PCB aborted with a FATAL ERROR, the ANSI characters were
>screwed up in the loacl node like it was dropping interrupts, any ideas?

Are you sure that the local node is "local" and not hooking into the same
IRQ used for the first node?  Do you have the programs set to swap to disk,
run in background and maintain background priority.

>I have added the AMRS=9 option to my config.sys which fixed the second
>node just looping with MODEM RESET ERRORS. I also notice that while both
>nodes of PCB are up, I can't get the MENU to come back by hitting
>CTRL-1( I have reassigned the key seq with ovsetup) it just displays the
>top of screen, but not the menu...

Do you have the SCREEN parameter as the last line in the 386^MAX config.sys
entry?

Date: 08-03-89 (19:46)              Number: 103 / 397
  To: DENNIS EDWARDS                Refer#: 99
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>You should also set AMRS=9. As for the stated INCLUDE, see below...

I have tried this and still no difference, the nodes work, but the
system is jerky and unresponsive to menu and other commands..

>For any COM program on a '386, select the following options:
>
>Runs in Background:        YES
>Lower Background Priority:     NO
>
>High Speed Communications:    NO
>    This is a short cut designed to aid users with systems based on
>    '286 and earlier CPU's. It simply changes other program form
>    options to elimnate swapping to disk, to maintain the background
>    priority and to enable running in the background.

I have HS COMMUNICATIONS set to YES, will change that and swap to disk
option and let you know! Thanks for all the help, one last thing , I

Date: 08-06-89 (12:55)              Number: 104 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 103
From: DENNIS EDWARDS                  Read: NO
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>>You should also set AMRS=9. As for the stated INCLUDE, see below...
>
>I have tried this and still no difference, the nodes work, but the
>system is jerky and unresponsive to menu and other commands..

Some delays in the response of the foreground program is to be expected.
You only have one processor. The more background processes and the
higher their priority/clock ticks the more noticable the degradation of the
forground task will be. The Scheduling application note (OV_NOTES.ZIP) goes
into detail about computing the relative CPU time a given process will
receive.

>I have HS COMMUNICATIONS set to YES, will change that and swap to disk
>option and let you know! Thanks for all the help, one last thing , I

Sorry but your message ended here.




Date: 08-07-89 (03:31)              Number: 105 / 397
  To: DENNIS EDWARDS                Refer#: 104
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: OV and PCB                                      Refer#: 106
From: DENNIS EDWARDS                  Read: NO
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>what improvements have been made from 4.10 to 4.13? Thanks!

Actually, I'm in the process of getting together a formal list which I
will post when completed.  As I recall...

'/V' command line option added for non-standard EGA's.
Improved interrupt handling on context switch.
Improved handling of bus mice.
COMMOUSE improved.
Improved documentation for utilities.
Seemless dual monitor support.
Improved screen handling in 43/50 line mode on switch.
SENDKEYS supports 16 bit escape sequences.
CONSNUMB introduced.
SMACS supports enhanced keyboards.




Date: 08-08-89 (12:23)              Number: 108 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 105
From: DENNIS EDWARDS                  Read: NO
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I would expect some delays, but foreground kind of stops!
...
>Can't run a system this way!!

I agree. I haven't experience this particular set of symptoms before and
it's odd.

When you get 4.13, be sure to save your copy of PROGRAMS.TVM somewhere; if
you run OMINSTAL it will overwrite your program defintions.  It could be
that the problems you are describing are the result of a problem that
occured in 4.10 during context switches. If this doesn't clear up when you
get 4.13 up, then try these two things:

1) Add the /K option to the initial OV startup command. This tells us to
   treat your keyboard as if it were an 83 key model; some keyboard BIOSs
   treat the KBX calls strangely.

2) If they aren't already, set the priority and clock ticks of the COM
   programs to that of the other processes, they could be the only things
   running.

Keep me posted.

Date: 08-09-89 (04:32)              Number: 109 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: ADDRAM10.ZIP                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Ran across an interesting program which expands on Dunford's EEMRAM and
provides a little more information about the hardware and EMS. Its
primary purpose appears to be to attempt to expand DOS memory above
640k, but I believe it could prove useful for working with expanded
implementations, too. It's downloadable. Here's what it reported on this
box (with Super PC-Kwik installed in expanded)


EMSDATA 1.00  Copyright (C) 1989 by Marty Del Vecchio

Expanded Memory Manager installed; EMS is version 4.0
EMM status is 0, OK.       Page frame segment is D800

Total Expanded Memory:       1048576 bytes (1024 KB, 64 pages)
Available Expanded Memory:         0 bytes (   0 KB,  0 pages)

EMM handles currently allocated: 2

Handle #      Name       Pages       Bytes
--------------------------------------------

   0                0             0    (backfill of DOS memory)
   1               64       1048576

System raw page size:        16384 bytes (standard)
Total raw pages:             64 (1024 KB)
Available raw pages:         0 (0 KB)
Additional register sets:    0
Context save area size:      5 bytes
DMA channels:                0

Since your EMS hardware has not backfilled memory into the DOS
range, a multitasking environment such as Desqview cannot support
high-speed multitasking among programs running in expanded memory.

Your EMS hardware is capable of mapping memory at 4 addresses.
Each of these segment addresses falls on a 16KB boundary.  Here
is a detailed listing of where your EMS board can map memory and
where it cannot.  You may be able to change these results by
changing the parameters to your EMS device driver in CONFIG.SYS.

  Address                   Hardware
   Range        Length      can map
-------------------------------------

0000 - D7FF      864KB        No
D800 - E7FF       64KB        Yes
E800 - FFFF       96KB        No

Your EMS card is not capable of mapping memory at segment address
A000.  Thus, you most likely will not be abble to use ADDRAM.COM
to extend your DOS memory beyond 640K.  If you have a monochrome
or CGA video card, you may have to explicitly tell your EMS software
that it can address memory at A000.  For most drivers, this can be
accomplished by adding a parameter such as '/i=A000-AFFF' to your
device driver line in CONFIG.SYS.  See ADDRAM.DOC for more details.

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 08-09-89 (04:37)              Number: 110 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: MORE FROM ADDRAM10            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Here's the NEAT 286, with the cache/ramdisk de-installed. Not too
unpredictably different.


EMSDATA 1.00  Copyright (C) 1989 by Marty Del Vecchio

Expanded Memory Manager installed; EMS is version 4.0
EMM status is 0, OK.       Page frame segment is D800

Total Expanded Memory:       1048576 bytes (1024 KB, 64 pages)
Available Expanded Memory:   1048576 bytes (1024 KB, 64 pages)

EMM handles currently allocated: 1

Handle #      Name       Pages       Bytes
--------------------------------------------

   0                0             0    (backfill of DOS memory)

System raw page size:        16384 bytes (standard)
Total raw pages:             64 (1024 KB)
Available raw pages:         64 (1024 KB)
Additional register sets:    0
Context save area size:      5 bytes
DMA channels:                0

Since your EMS hardware has not backfilled memory into the DOS
range, a multitasking environment such as Desqview cannot support
high-speed multitasking among programs running in expanded memory.

Your EMS hardware is capable of mapping memory at 4 addresses.
Each of these segment addresses falls on a 16KB boundary.  Here
is a detailed listing of where your EMS board can map memory and
where it cannot.  You may be able to change these results by
changing the parameters to your EMS device driver in CONFIG.SYS.

  Address                   Hardware
   Range        Length      can map
-------------------------------------

0000 - D7FF      864KB        No
D800 - E7FF       64KB        Yes
E800 - FFFF       96KB        No

Your EMS card is not capable of mapping memory at segment address
A000.  Thus, you most likely will not be abble to use ADDRAM.COM
to extend your DOS memory beyond 640K.  If you have a monochrome
or CGA video card, you may have to explicitly tell your EMS software
that it can address memory at A000.  For most drivers, this can be
accomplished by adding a parameter such as '/i=A000-AFFF' to your
device driver line in CONFIG.SYS.  See ADDRAM.DOC for more details.

PCRelay:POVTEST -> RelayNet (TM)
                   Poverty Rock Test System + Seattle WA +

Date: 08-09-89 (12:02)              Number: 111 / 397 (Echo)
  To: RICK KUNZ                     Refer#: 109
From: DENNIS EDWARDS                  Read: 08-09-89 (15:53)
Subj: ADDRAM10.ZIP                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Ran across an interesting program which expands on Dunford's EEMRAM and
>provides a little more information about the hardware and EMS.
>...
>EMSDATA 1.00  Copyright (C) 1989 by Marty Del Vecchio
>
>Expanded Memory Manager installed; EMS is version 4.0
>...
>System raw page size:        16384 bytes (standard)
>Total raw pages:             64 (1024 KB)
>Available raw pages:         0 (0 KB)
>Additional register sets:    0
>Context save area size:      5 bytes
>DMA channels:                0
>is a detailed listing of where your EMS board can map memory and
>where it cannot.  You may be able to change these results by
>changing the parameters to your EMS device driver in CONFIG.SYS.
>
>  Address                   Hardware
>   Range        Length      can map
>-------------------------------------
>
>0000 - D7FF      864KB        No
>D800 - E7FF       64KB        Yes
>E800 - FFFF       96KB        No

Great info, Rick. I believe that this data is obtained by calling EMM
functions 25h (Get Mappable Physical Address Array) and 26h (Get EMS
Hardware Information).

OMNIVIEW automatically topfills to the bottom of the video adapter, if it
can. The illustrated diagnostics from the EMSDATA program, though, could be
very valuable - especially to those considering an investment in LIM 4.0
hardware.

Thanks again, I'll download it.

Date: 08-09-89 (12:02)              Number: 112 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: ADDRAM10.ZIP and LIM 4.0      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

In an earlier message Rick Kunz describes an EMS utility available as
ADDRAM10.ZIP.  Part of the output from the EMSDATA program in that utility
package is shown below. Since this data appears to be useful in evaluating
the functionality of EMS systems, this message will correlate the
information in the utilty's output to the requirements of a multitasker.

>EMSDATA 1.00  Copyright (C) 1989 by Marty Del Vecchio
>
>Expanded Memory Manager installed; EMS is version 4.0
>EMM status is 0, OK.       Page frame segment is D800
>
>Total Expanded Memory:       1048576 bytes (1024 KB, 64 pages)
>Available Expanded Memory:         0 bytes (   0 KB,  0 pages)
>
>EMM handles currently allocated: 2
>
>Handle #      Name       Pages       Bytes
>--------------------------------------------
>
>   0                0             0    (backfill of DOS memory)
>   1               64       1048576
>
>System raw page size:        16384 bytes (standard)
>Total raw pages:             64 (1024 KB)
>Available raw pages:         0 (0 KB)
>Additional register sets:    0
>...
>Your EMS hardware is capable of mapping memory at 4 addresses.
>Each of these segment addresses falls on a 16KB boundary.
>...

To maintain the terminology I've been using here, I'd paraphrase the first
part of the last quoted paragraph as: "The EMS hardware has 4 physical
pages for a total of 64K of mappable EMS memory. The system's raw page size
is 16K and each block of EMS must be aligned on a multiple of this page
size; therefore, each of the hex paragraph addresses shown in the table
below begins on a 16K boundary.".

Note: (raw page size) * (number of physical pages) = physical EMS memory
        16K       *             4              = 64K

To determine the required mimimum amount of physical EMS for a given
system, add up the amount of backfill and topfill you'll need, then add 48K
for using OMNIHIGH as well as 64K to support the page frame. It takes 64K
to topfill to an MDA and 96K to topfill to a CGA. To backfill to 256K,
topfill to the bottom of a CGA, run OMNIHIGH, and provide a page frame; the
amount of physical EMS memory you will need is:

(640k - 256K) + 96K + 48K + 64K = 592K of physical EMS

To get the required number of mapping registers need for this much memory,
divide the required physical memory by the size of that system's physical
page. If the "System raw page size" is the 16K shown above (bytes/1024=K)
then you would need:

592K / 16K = 37 physical pages of EMS

When looking at the output of the EMSDATA program then, the system would
need to be capable of "mapping memory at 37 locations". If you can map
memory at more locations that's OK, you have room to grow. If the number is
less than you computed then it won't do what you want.

Note that the "Total Expanded Memory" and "Available Expanded Memory"
represent the amount of EMS memory that is in the system and currently
available, respectively.  These numbers refer to memory that can be
"logically" accessed by changing the EMS context and is an entirely
different thing from the amount of _physical_ EMS memory which can accessed
at any given time _without changing_ the EMS context.

To determine the total amount of EMS that you will need, add up the sizes
of all the programs you will want to run at the same time, then add 48K for
running OMNIHIGH and finaly, add in the amount of EMS used by each of the
running programs (including disk caches, ram drives, etc.). The partition
size you set up for a given program is how much memory it needs. Figure at
least 64K for use by your applications.

EMSDATA's "Additional register sets" is a count of the Alternate Mapping
Register Sets (AMRS). This is an aspect of the hardware used to store an
EMS context.  Since there is always one set of mapping registers and since
each process that you want to run has its own context, you will want your
system to have (The most you will need for OMNIVIEW is nine):

((max number of tasks operating at the same time) - 1) AMRSs

The LIM 4.0 standard does not specify the number of physical pages or AMRSs
that a system must support. The standard does specify that the minimum
number of "handles" that the EMS software must support is 64. Since a
handle is used to identify a block of memory, I understand the standard to
imply that at least 64 physical pages be available; other interpretations
are, of course, available.

Date: 08-09-89 (15:59)              Number: 113 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: 112
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: ADDRAM10.ZIP and LIM 4.0      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Glad that program looks useful, Dennis. I think I'll go ahead and
forward it to NETNODE so that others can request it through the
RelayNet. It's 27k in size.

Date: 08-10-89 (08:54)              Number: 114 / 397 (Echo)
  To: RICK KUNZ                     Refer#: 113
From: DENNIS EDWARDS                  Read: 08-10-89 (18:18)
Subj: ADDRAM10.ZIP and LIM 4.0      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Glad that program looks useful, Dennis. I think I'll go ahead and
>forward it to NETNODE...

What would think of an OV "expert system" -- you'ld stick this program
into a 640K "show room" machine and run it.  It would look around at where
it was loaded in memory and check out the EMS system and video adapter
then estimate the number and size of concurrent processes that could be
run, largest partition size, amount of EMS you'ld have left over for apps
etc- as well as the EMSINFO stuff.



Date: 08-10-89 (18:20)              Number: 115 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: 114
From: RICK KUNZ                       Read: 12-06-89 (11:28)
Subj: ADDRAM10.ZIP and LIM 4.0      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>What would think of an OV "expert system" -- you'ld stick this program
>into a 640K "show room" machine and run it.  It would look around at wh
>it was loaded in memory and check out the EMS system and video adapter
>then estimate the number and size of concurrent processes that could be
>run, largest partition size, amount of EMS you'ld have left over for
>apps etc- as well as the EMSINFO stuff.

 I like it a bunch. I think it would help people configure their systems
 with far less hassle than they might if they didn't know all that much
 about it -- I would use it myself, I think! <grin>

Date: 08-12-89 (23:09)              Number: 116 / 397
  To: DENNIS EDWARDS                Refer#: 108
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>>I would expect some delays, but foreground kind of stops!
>...
>>Can't run a system this way!!
>
>I agree. I haven't experience this particular set of symptoms before an
>it's odd.
>you run OMINSTAL it will overwrite your program defintions.  It could b
>that the problems you are describing are the result of a problem that
>occured in 4.10 during context switches. If this doesn't clear up when

I have 4.13 and the problems were the same, I figured since I am only
one having this problem it must be a software conflict with something so
I started removing things! It turns out the cause was in my CONFIG.SYS I
had a SHELL statement to increase my enviornment! Why is this causing
troubles!! And now what do I do since I put the SHELL in there for a
reason! Also I notice that when I try that little bat routines you sent
out to bring up a BBS automatically I seem to have trouble, it comes out
and flashes error about out of virtual memory and something about
allocation, here is my little bat, I use the first START.BAT to start OV
then it calls up STARTBBS.BAT to bring up 2 nodes, what is wrong here-

my START.BAT-
OMNIVIEW /PB /M:128 /D:SCR:NOWAIT;EMS;ICA C:\COMMAND.COM /C
(on same line as above) C:\OV\STARTBBS.BAT

STARTBBS.BAT-
SPAWN /PB /M:384 /C:2 /P:3 /D:SCR:NOWAIT;EMS;ICA C:\PCB\DVBOARD.BAT
SPAWN /PB /M:384 /C:2 /P:3 /D:SCR:NOWAIT;EMS;ICA D:\PCB2\DVBOARD.BAT


Thanks for help!

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 08-14-89 (14:42)              Number: 117 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 116
From: DENNIS EDWARDS                  Read: NO
Subj: OV and PCB                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>It turns out the cause was in my CONFIG.SYS I
>had a SHELL statement to increase my enviornment! Why is this causing
>troubles!! And now what do I do since I put the SHELL in there for a
>reason!

I don't know why a SHELL statement that simply specified an environment
size would give OV trouble - this is something I've never experienced and I
use a shell statement to expand the parent environment all the time.  What
_is_ the reason why you need the SHELL statement? What programs need the
strings? What are the strings? How are you adding strings? When are you
adding them? Are you trying to edit them (if so how)? etc.

Keep in mind the following about the environment:

1) The default size is 160 bytes and adding the /e parameter in the
   shell command only changes the size of the _parent_ environment. It does
   not effect the allocation of memory for any copies of the environment.

2) Only the defined environment strings are duplicated in copies of the
   environment (and then padded to a paragraph boundary). This is because
   the environment is intended to be "read only".

If want to be able to expand the environment of a child COMMAND.COM you
have to give the /e=N parameter TO EACH COPY of COMMAND that you want to
run. You should be able to do this with %COMSPEC%.


>Also I notice that when I try that little bat routines you sent
>out to bring up a BBS automatically I seem to have trouble, it comes out
>and flashes error about out of virtual memory and something about
>allocation, here is my little bat, I use the first START.BAT to start OV
>then it calls up STARTBBS.BAT to bring up 2 nodes, what is wrong here-
>
>my START.BAT-
>OMNIVIEW /PB /M:128 /D:SCR:NOWAIT;EMS;ICA C:\COMMAND.COM /C
>(on same line as above) C:\OV\STARTBBS.BAT
>
>STARTBBS.BAT-
>SPAWN /PB /M:384 /C:2 /P:3 /D:SCR:NOWAIT;EMS;ICA C:\PCB\DVBOARD.BAT
>SPAWN /PB /M:384 /C:2 /P:3 /D:SCR:NOWAIT;EMS;ICA D:\PCB2\DVBOARD.BAT

Remember, everything needs to be swappable on a '386 because all the
virtual EMS is treated like a common memory pool.  Add the /S parameter to
the OMNIVIEW and SPAWN commands.

Date: 08-13-89 (20:36)              Number: 118 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: OV 4.13                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, I am making progress slowly, semms I now have those sample bats
set to bring up system unattened, now insted of getting those virtual
allocation errors I get what looks like normal startup I see it load
partitions (comes back with message saying so!) then it says OMNIVIEW
dismounted from memory? am i doing something wrong? here are the bat
files again..

This is the START.BAT-

OMNIVIEW /S /PB /M:416 /D:SCR:NOWAIT;EMS;ICA C:\COMMAND.COM /C
C:\OV\STARTBBS.BAT


This is the STARTBBS.BAT-

SPAWN /S /PB /M:384 /C:2 /P:3 /D:SCR:NOWAIT;EMS;ICA C:\PCB\DVBOARD.BAT
SPAWN /S /PB /M:384 /C:2 /P:3 /D:SCR:NOWAIT;EMS;ICA D:\PCB2\DVBOARD.BAT


Thanks! Once these are eventually loaded ( after we shoot these bugs) do
I switch between partitions with the OV-Key # to bounce back and
forth... Thanks again!

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 08-15-89 (11:50)              Number: 119 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: 118
From: DENNIS EDWARDS                  Read: NO
Subj: OV 4.13                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Dennis, I am making progress slowly, semms I now have those sample bats
>set to bring up system unattened, now insted of getting those virtual
>allocation errors I get what looks like normal startup I see it load
>partitions (comes back with message saying so!) then it says OMNIVIEW
>dismounted from memory?

I suspect that that all the batch files are "done": This would cause
COMMAND.COM (which contains the batch file interpreter) to exit. Whenever
the initial program controlling a partition exits, the partition is closed.
Thus OMNIVIEW has nothing to do and so it, too, exits (giving you the
"dismounted" message). You can verify this by changing the OMNILOAD.BAT
file (which I uploaded to the NET via POVERTY) to reflect your startup
command -- the batch file will indicate a normal OMNIVIEW exit if I am
right.

To stop the first partition from closing, either add "C:\COMMAND" or
"%COMSPEC%" to the last line of START.BAT. The advantage of COMSPEC is that
you can change your command interpreter from COMMAND.COM to 4DOS (or
whatever) somewhere down the line and not have to modify your OV batch
files -- assuming you set the COMSPEC environment variable, of course.

I don't know what the deal is with the DVBOARD.BAT files. If I had to guess
I'd say they are looking for a program you don't have running and exiting
"on error" when it is not found. Post them if you want.

BTW...did you solve the environment problem?

>Thanks! Once these are eventually loaded ( after we shoot these bugs) do
>I switch between partitions with the OV-Key # to bounce back and
>forth... Thanks again!

Yes. The default is the combination of the Ctrl, Left Shift, and "the key
labeled with the relevent partition number on the numeric keypad".  You
can use OVSETUP to change the shift state and also switch between the
numeric keypad and QWERTY number keys.

Date: 08-16-89 (20:35)              Number: 120 / 397
  To: ALL                           Refer#: NONE
From: DON BARBA                       Read: (N/A)
Subj: HELLO FROM BROOKLYN,NY        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

MoonDog BBS in Brooklyn,New York is participating
in this conference.

PCRelay:MOONDOG -> RelayNet (TM)
                   MoonDog BBS Brooklyn,NY 718 692-2498 9600-V

Date: 08-18-89 (09:53)              Number: 121 / 397 (Echo)
  To: DON BARBA                     Refer#: 120
From: DENNIS EDWARDS                  Read: NO
Subj: HELLO FROM BROOKLYN,NY        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

▐MoonDog BBS in Brooklyn,New York is participating
▐in this conference.

Welcome! Hope you enjoy the conference.

Date: 08-18-89 (05:13)              Number: 122 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: BOB HUNTER                      Read: 12-06-89 (11:28)
Subj: ORDER                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Well, after your message during the last of July I ordered Omniveiw.
I am still waiting to receive it, however. Could you post the sales
number again so I can track when delivery might take place? I was given
a 4 day shipping date and it has been 16 days.

PCRelay:CHEMEK -> RelayNet (TM)
                  Chemeketa OnLine [phone] Salem, OR

Date: 08-20-89 (09:22)              Number: 123 / 397 (Echo)
  To: BOB HUNTER                    Refer#: 122
From: DENNIS EDWARDS                  Read: NO
Subj: ORDER                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

▐Well, after your message during the last of July I ordered Omniveiw.

Sunny Hill order desk:          [phone]

Thanks for the order. I will follow up on this myself.

Date: 08-22-89 (20:13)              Number: 124 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: BBS                           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis,
In a previous message you mentioned a bat file LOADEMUP.BAT you were
gonna upload to the net, yet the NETHUB has not yet received it! Now as
per our earlier conversations I have made some progress! I seem to have
semi-fixed the enviornment problem, but I still have sluggish problem
when starting from MENu, how would I increase the enviornment of the
menu partition and the supsequent BBS partitions! Below are the new BAT
files I use to start up my system under OV when not using menu-

This is START.BAT to get OV started-

OMNIVIEW /S /PB /M:256 /C:1 /P:2 /D:SCR:NOWAIT;EMS;ICA C:\COMMAND.COM
/E:2048 /C C:\OV\STARTBBS.BAT

It calls up STARTBBS.BAT as such-

spawn /s /PB /M:128 /C:1 /P:2 /D:SCR:NOWAIT c:\command.com /E:2048
SPAWN /S /PB /M:448 /C:2 /P:4 /D:SCR:NOWAIT;EMS;ICA c:\command.com
/E:2048 /C C:\PCB\DVBOARD.BAT
SPAWN /S /PB /M:448 /C:2 /P:4 /D:SCR:NOWAIT;EMS;ICA c:\command.com
/E:2048 /C D:\PCB2\DVBOARD.BAT


Now several bumps I have hit, first the First SPAWN is a DOS partition I
am trying to open to allow me ability to open other partitions if the
both BBs nodes are in use, but this DOS partition just comes up with C:>
Prompt and is frozen. Also the screen in partiton 1 locked showing the
spawn lines and the partitions strted, but is unusable. Can I make that
my DOs partition, or can I have it so the SHELL MENU is loaded there?
If I can't make that Partiton 1 (start.bat) usefull, can it be removed
in bat file to allow least overhead wasted, If I CTRL-ALT-DEL it all
keeps running smooth! BTW- I have received 4.13 now and none of my
previous problems were due to 4.10. I am also running 386MAX 4.07 !

PCRelay:PHANTASM -> RelayNet (tm)
                    PHANTASM 201-291- 2302(USR DUAL)/4134(HAYESV)

Date: 08-26-89 (16:53)              Number: 125 / 397 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: STEVE STROH                     Read: 12-06-89 (11:28)
Subj: SIMPLE QUESTIONS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I haven't gotten on lately, so some of the messages might have scrolled
off while I was away, so pardon if this has already been posted.

I've had Omniview for about a month now, and I'm relatively happy with
it, although I think it's capabilities (limited by the problems of the
286) were a bit oversold.

My most annoying problem is that I have a batch file configured to load
the stuff I'm want into the various partitions.  Even though I have
swap to disk set, whenever Omniview tries to load the next partition
and it's out of memory, IT WON'T SWAP THE PARTITIONS PREVIOUSLY LOADED
out to disk.  Grrrrr!

A secondary problem is that in the batch file, I have it start up a
couple of DOS partitions, and then I TRY to have it load a couple of DOS
utilities (reset the prompt, and a dos history TSR).  Anything other
than the line that loads dos is ignored for that partition.  (it skips
the utility lines and loads the next partition).

A relatively minor one is that the first partition that I can load is
always #2.  Wish I could load #1.

I always considered myself a fairly knowlegeable DOS user, but trying to
get Omniview running has caused me to get up and walk away in
frustration more times than any other program I've used.  Don't get me
wrong, I'm happy with it (mostly- I've GOT to be doing something wrong
in the primary problem above), and recognize that there's only so much
you can do with a brain dead 286 and 640 of normal memory and 384 of
extended.  No doubt Sunny Hill doesn't have unlimited resources, but it
sure seems like more attention could have been paid to the manual and
had more examples.  <It simply isn't possible to have too many examples-
JE Pournelle).

I know the above descriptions border on vague, but if you can give me
some pointers, I'll get back on here with exact error messages, etc.
Your tech support guy(s?) (who doesn't go out of his way to identify
himself) is good- he knows the answers, but he has problems adjusting
his baud rate to match the level of the caller.  But always, without
fail, friendly, curteous, and as helpful as he knows how.  He said post
questions here and it might be more effective.

Thanks!
Steve Stroh

Date: 08-28-89 (11:25)              Number: 126 / 397 (Echo)
  To: STEVE STROH                   Refer#: 125
From: DENNIS EDWARDS                  Read: 09-07-89 (07:12)
Subj: SIMPLE QUESTIONS              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

▌My most annoying problem is that I have a batch file configured to load
▌the stuff I'm want into the various partitions.  Even though I have
▌swap to disk set, whenever Omniview tries to load the next partition
▌and it's out of memory, IT WON'T SWAP THE PARTITIONS PREVIOUSLY LOADED
▌out to disk.  Grrrrr!

Without seeing the batch files you're using it's difficult to say why this
is happening. It does work though.

There are a couple of reasons why you would get a "not enough memory" error
when trying to load a program:

1) You are out of "swap" space. This can happen because the physical disk
   you started OV from actually has less room than is required to move
   all the required existing partitions to disk but, more often, it is
   because one has an LIM 4.0/EEMS system or a RAM disk.  In the case of a
   RAM disk the solution is to eliminate the "SWAP=" environment variable
   or point it to a physical drive that has enough free space to hold the
   partitions you want to swap out (or buy more RAM).  Omniview always
   uses the same swapping disk.  If you have LIM 4.0/EEMS then you can
   either buy more RAM or else decide that swapping is more important than
   EMS concurrency (on a '286 or below, as I've said several times, the
   size of a concurrent process will be limited by the amount of backfill).
   If you start OMNIVIEW with the "/E" command line switch, OV will treat
   all EMS in the system as LIM 3.2 memory and then when the EMS fills up,
   it will overflow to the physical disk.

2) The partition that you are trying to load is larger than the amount of
   memory you have free after OV loads. You can compare the size of the
   partition to the "largest free block" reported by OVSTAT to see if this
   is true. The only things to do here are to reduce the partition size or
   increase the available space. To increase the avialable space remove
   TSRs that were installed before OMNIVIEW, kill the non-swappable
   partitions or get a LIM 4.0 system and load OMNIVIEW into high memory
   (LIM 4.0 can also fill in to the bottom of the video adapter to increase
   the TPA on monochrome and CGA systems).

3) You have not made all the partitions swappable - a non-swappable
   partition permanently detracts from the available TPA.

4) You are trying to open the partition from within another partition that
   must be swapped out in order to fit the new one into memory. Without the
   current partition being completely within LIM 4.0/EEMS, this would
   require that the current partition be physically copied into the swap
   space before it is done executing - something that is impossible to do.
   The answer to this problem is to create a small, non-swappable "control
   partition" as the initial process and then load all subsequent processes
   from that partition.  When you use the menus (OVSHEL/XSHELL), "the
   shell" serves as the control partition; either way, the control
   partition is effectively nonswappable.

▌A secondary problem is that in the batch file, I have it start up a
▌couple of DOS partitions, and then I TRY to have it load a couple of DOS
▌utilities (reset the prompt, and a dos history TSR).  Anything other
▌than the line that loads dos is ignored for that partition.  (it skips
▌the utility lines and loads the next partition).
▌
▌A relatively minor one is that the first partition that I can load is
▌always #2.  Wish I could load #1.

I don't understand this, either, the first partition that OV creates is
_always_ #1. I suspect that partition #1 is dying for want of
anything to do: Running a batch file that loads TSRs as the last thing it
does will die when the batch file is completed. The reason it dies is
because it returns an exit code (meaning DOS tells OV that the program(s)
in that partition no longer exist); the way around this is to reload a copy
of the command processor as the last line in the batch file that runs in
the vanishing partition (see below).

C>copy con somefile.bat
spawn /S /m:xxx program1.exe
spawn /S /m:xxx program2.com
youtsr
itsr
wealltsr
%COMSPEC%
^Z

C>omniview /m:xxx /d:scr:fast \command.com /c somefile.bat

Note that in the above examples the partition that executes somefile.bat is
nonswappable: This would make partition #1 the "control partition".
%COMSPEC%, of course, reloads the transient portion of the user specified
command processor (COMMAND.COM by default) into memory and makes it the
current program in that partition: typing "exit" at the DOS prompt will
remove that partition.

If none of this works for you then please post the batch files you're
using. This will allow me to make more specific suggestions.

Date: 08-28-89 (11:25)              Number: 127 / 397 (Echo)
  To: KEITH LUKEN                   Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: bbs                           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

▌In a previous message you mentioned a bat file LOADEMUP.BAT you were
▌gonna upload to the net, yet the NETHUB has not yet received it!

I'll check on this. The file was put on POVERTY and I'm sure that Rick sent
it - I don't know what the problem is.

I'll just post it.

▌Now as
▌per our earlier conversations I have made some progress! I seem to have
▌semi-fixed the enviornment problem, but I still have sluggish problem
▌when starting from MENu, how would I increase the enviornment of the
▌menu partition and the supsequent BBS partitions!

1)build dummy variables so that the environment actually holds the
  desired number of strings
2)Start up a DOS partition of 55K and then run OVSHELL.COM. On the Program
  Form Startup Comman
d field specify: C:\COMMAND.COM /E:2048

▌Below are the new BAT
▌files I use to start up my system under OV when not using menu-
▌
▌This is START.BAT to get OV started-
▌
▌OMNIVIEW /S /PB /M:256 /C:1 /P:2 /D:SCR:NOWAIT;EMS;ICA C:\COMMAND.COM
▌/E:2048 /C C:\OV\STARTBBS.BAT
▌
▌It calls up STARTBBS.BAT as such-
▌
▌spawn /s /PB /M:128 /C:1 /P:2 /D:SCR:NOWAIT c:\command.com /E:2048
▌SPAWN /S /PB /M:448 /C:2 /P:4 /D:SCR:NOWAIT;EMS;ICA c:\command.com
▌/E:2048 /C C:\PCB\DVBOARD.BAT
▌SPAWN /S /PB /M:448 /C:2 /P:4 /D:SCR:NOWAIT;EMS;ICA c:\command.com
▌/E:2048 /C D:\PCB2\DVBOARD.BAT
▌
▌
▌Now several bumps I have hit, first the First SPAWN is a DOS partition I
▌am trying to open to allow me ability to open other partitions if the
▌both BBs nodes are in use, but this DOS partition just comes up with C:>
▌Prompt and is frozen. Also the screen in partiton 1 locked showing the
▌spawn lines and the partitions strted, but is unusable.

The partition doesn't have a high enough priority to run. Remove the /P
statements from all the SPAWN lines and the initial OMNIVIEW command. If
all partitions have default priority that is not reduced in background then
the CPU time will split the CPU time equally.  If you leave off the /PB as
well then the foreground partition will get 50% and the remaining 50% will
be equally divided among the background processes.

Make sure set you AMRS=9 for 386^MAX.


Date: 08-28-89 (11:25)              Number: 128 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: omniload.bat, part 1          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

ECHO OFF
PLOAD %COMSPEC% /C OMNIVIEW /D:SCR:FAST /S %1 %2 %3 %4 %5 %6 %7 %8 %9
IF ERRORLEVEL==3 GOTO DOS3STRT
GOTO DONE
:DOS3STRT
OMNIVIEW %1 %2 %3 %4 %5 %6 %7 %8 %9
if errorlevel 1 goto ERR104
echo OMNIVIEW: Normal exit, no processes running.
goto DONE
:ERR104
if errorlevel 103 goto ERRUNKNOWN
if not errorlevel 102 goto ERR101
echo OMNIVIEW: Semaphore is set.
goto DONE
:ERR101
if not errorlevel 101 goto ERR100
echo OMNIVIEW: Exclusive semaphore already owned.
goto DONE
:ERR100
if not errorlevel 100 goto ERR95
echo OMNIVIEW: Too many semaphores.
goto DONE
:ERR95
if errorlevel 96 goto ERRUNKNOWN
if not errorlevel 95  goto ERR93
echo OMNIVIEW: System call interrupted.
goto DONE
:ERR93
if errorlevel 94 goto ERRUNKNOWN
if not errorlevel 93  goto ERR92
echo OMNIVIEW: No items found to work on.
goto DONE
:ERR92
if not errorlevel 92  goto ERR91
echo OMNIVIEW: Timer service table duplicate.
goto DONE
:ERR91
if not errorlevel 91  goto ERR90
echo OMNIVIEW: Timer service table overflow.
goto DONE
:ERR90
if not errorlevel 90  goto ERR89
echo OMNIVIEW: Not frozen error.
goto DONE
:ERR89
if not errorlevel 89  goto ERR88
echo OMNIVIEW: No process slots available.
goto DONE
:ERR88
if not errorlevel 88  goto ERR87
echo OMNIVIEW: Network write fault.
goto DONE
:ERR87
if not errorlevel 87  goto ERR86
echo OMNIVIEW: Invalid parameter.
goto DONE
:ERR86
if not errorlevel 86  goto ERR85
echo OMNIVIEW: Invalid password.
goto DONE
:ERR85
if not errorlevel 85  goto ERR84
echo OMNIVIEW: Already assigned.
goto DONE
:ERR84
if not errorlevel 84  goto ERR83
echo OMNIVIEW: Out of structures.
goto DONE
:ERR83
if not errorlevel 83  goto ERR82
echo OMNIVIEW: Interrupt 24 fail.
goto DONE
:ERR82
if not errorlevel 82  goto ERR81
echo OMNIVIEW: Cannot make item.
goto DONE
:ERR81
if not errorlevel 81  goto ERR80
echo OMNIVIEW: Duplicated FCB error.
goto DONE
:ERR80
if not errorlevel 80  goto ERR18
echo OMNIVIEW: File exists.
goto DONE
:ERR18
if errorlevel 19 goto ERRUNKNOWN
if not errorlevel 18  goto ERR17
echo OMNIVIEW: No more files.
goto DONE
:ERR17
if not errorlevel 17  goto ERR16
echo OMNIVIEW: Not same device.
goto DONE

Date: 08-28-89 (11:25)              Number: 129 / 397 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: omniload.bat, part 2          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

if not errorlevel 16  goto ERR15
echo OMNIVIEW: Current directory error.
goto DONE
:ERR15
if not errorlevel 15  goto ERR13
echo OMNIVIEW: Invalid drive.
goto DONE
:ERR13
if errorlevel 14 goto ERRUNKNOWN
if not errorlevel 13  goto ERR12
echo OMNIVIEW: Invalid data.
goto DONE
:ERR12
if not errorlevel 12  goto ERR11
echo OMNIVIEW: Invalid access.
goto DONE
:ERR11
if not errorlevel 11  goto ERR10
echo OMNIVIEW: Bad format error.
goto DONE
:ERR10
if not errorlevel 10  goto ERR9
echo OMNIVIEW: Bad environment.
goto DONE
:ERR9
if not errorlevel 9 goto ERR8
echo OMNIVIEW: Invalid block.
goto DONE
:ERR8
if not errorlevel 8 goto ERR7
echo OMNIVIEW: Not enough memory.
goto DONE
:ERR7
if not errorlevel 7 goto ERR6
echo OMNIVIEW: Memory arena trashed.
goto DONE
:ERR6
if not errorlevel 6 goto ERR5
echo OMNIVIEW: Invalid handle.
goto DONE
:ERR5
if not errorlevel 5 goto ERR4
echo OMNIVIEW: Access denied.
goto DONE
:ERR4
if not errorlevel 4 goto ERR3
echo OMNIVIEW: Too many open files.
goto DONE
:ERR3
if not errorlevel 3 goto ERR2
echo OMNIVIEW: Path not found.
goto DONE
:ERR2
if not errorlevel 2 goto ERR1
echo OMNIVIEW: File not found.
goto DONE
:ERR1
if not errorlevel 1 goto ERRUNKNOWN
echo OMNIVIEW: Invalid function.
goto DONE
:ERRUNKNOWN
echo OMNIVIEW: Unknown error.
:DONE

Date: 09-05-89 (20:01)              Number: 130 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: BOB HUNTER                      Read: 12-06-89 (11:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis - Earlier I left a message about the long wait for shipping. You
had indicated you would look into it. Have you heard anything? I called
the sales line and was told that it would be shipped the last Wednesday
in August UPS Blue Label. If I remember that is two day shipping. As of
09/5/89 still no product. Any help or hope?

Thanks for your time.

Bob Hunter

PCRelay:CHEMEK -> Chemeketa OnLine [phone] Salem, OR

Date: 09-06-89 (20:40)              Number: 131 / 397
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: SPEED                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis,
I finally have gotten OV to run with both nodes of my BBs, very smooth.
My only concern is I need soem tips on optimizing the thruput! I did
numerous bench tests and on a similar Desqview setup I made comparisons
of how the thruputs compared! I had a 19200 connection to a node while
other node was idle! I am using 2 USR HST's which in a stand alone
enviornment average about 1550CPS as my benchmark! under DV the CPS was
usually around 1440 cps which is not bad, but under OV I was never able
to get above 1232 cps!! I tried different clock ticks of 2 and 3 per
partition and no difference! I am so close to going LIVE with OMNIVIEW
so if you could just give me some fine-tuning advice!! THANKS!!


Date: 09-09-89 (13:02)              Number: 133 / 397 (Echo)
  To: BOB HUNTER                    Refer#: 130
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis - Earlier I left a message about the long wait for shipping.

I did follow up, was told the same as you and that you'ld be phoned to
explain. Checking again I'm told a "shipping frenzy" is currently in
progress. I will check again on Monday to make sure it has gone out.
Sorry about this.

Date: 09-09-89 (13:02)              Number: 133 / 572 (Echo)
  To: BOB HUNTER                    Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis - Earlier I left a message about the long wait for shipping.

I did follow up, was told the same as you and that you'ld be phoned to
explain. Checking again I'm told a "shipping frenzy" is currently in
progress. I will check again on Monday to make sure it has gone out.
Sorry about this.

Date: 09-09-89 (13:03)              Number: 134 / 572 (Echo)
  To: KEITH LUKEN                   Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: SPEED                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis,
│I finally have gotten OV to run with both nodes of my BBs, very smooth.
│My only concern is I need soem tips on optimizing the thruput! I did
│numerous bench tests and on a similar Desqview setup I made comparisons
│of how the thruputs compared! I had a 19200 connection to a node while
│other node was idle! I am using 2 USR HST's which in a stand alone
│enviornment average about 1550CPS as my benchmark! under DV the CPS was
│usually around 1440 cps which is not bad, but under OV I was never able
│to get above 1232 cps!!

Its difficult to say what the root of the disparity is without seeing your
current config. I suspect that you are giving the "idle" process more time
than you intend. I would also expect that, were the second node actually
loaded, the relative comparison would be more favorable.

When it's time for OV to schedule the next process it looks for the next
highest priority process, other than the current process, and runs it if it
can. To illustrate the scheduling process consider the following relative
priorities, where A,B,C and D are processes listed in order of priority

Case 1:     A
            B, C, D

In this situation all procs have the default priority and equal ticks and
proc. A is foreground.  The scheduling pattern will be (ABACADAB...) and the
foreground partition will get 50% of the CPU time. Each of the background
procs will split the remaing CPU time equally.

Case 2:     A, B
            C, D

This is similar to the above situation except that proc B does not have its
background priority reduced. The scheduling pattern will be (ABAB). A and B
will split the CPU time and, unless they are handling a hardware interrupts,
procs C and D will never run.

Case 3:     A
            B
            C, D

This situation could result from a variety of priority value assignments -
only the relative ranking of priorities is important. The scheduling pattern
and relative CPU time will be the same as in Case 2.

Case 4:     A
            B, C
            D

This situation can also result from a variety of priority assignments. The
scheduling pattern would be (ABACAB).  Proc A would get 50% of the CPU time
while B and C would both run 25% of the time.

To determine the percentage of the CPU time that a given process uses, first
determine the scheduling pattern and then sum the quantas for the running
processes. Generally, the CPU time allotted to a given process is the ratio
of that processes' quanta to the sum of all the clock tick values.

There are are specific exceptions to this scheduling pattern which occure
when a program is waiting for some resource to become available, during which
time it will not run: A background program waiting on mouse or keyboard input
would fall into this catagory.

Another exception to the scheduling rule comes in when a program is "inside"
DOS during which time other programs are not scheduled, even though it may be
time to do so. You can see this happen when you start typing at the DOS
command line since, until you hit <enter>, DOS will not return from the "get
buffered input" call and all the background processes will remain idle
(except for interrupt handling - which is a seperate consideration from the
scheduling process).

As it turns out, the default priorities and clock value assignments work well
on a '386 - I would try those and compare the systems again under actual
loading conditions. The ANSI driver also effects the overall throughput of an
OV system.

Date: 09-11-89 (09:53)              Number: 135 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: Revised Application Notes     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

A revised set of OMNIVIEW Application Notes is being sent to the network
with the name OVAPPN00.ZIP.

Scheduling and Memory have been revised to amplify the effect of waiting
processes and add more specific information for 386 systems.

Date: 09-11-89 (09:53)              Number: 136 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: CONCURE.ZIP                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have uploaded a utility program to the network called CONCURE.ZIP.

This program is an "expert system" that can be useful in evaluating a
system's capability for use with a DOS multitasker.  The program offers
specific information about the number and size of OMNIVIEW processes that can
be expected to run CONCURrently. This program also evaluates the extent to
which a "LIM 4.0" system supports multitasker operation and so can have
diagnostic benefit.

Date: 09-11-89 (06:06)              Number: 137 / 572
  To: DENNIS EDWARDS                Refer#: 134
From: KEITH LUKEN                     Read: 12-06-89 (11:28)
Subj: SPEED                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Its difficult to say what the root of the disparity is without seeing y
>current config. I suspect that you are giving the "idle" process more t
>than you intend. I would also expect that, were the second node actuall
>loaded, the relative comparison would be more favorable.

>As it turns out, the default priorities and clock value assignments wor
>on a '386 - I would try those and compare the systems again under actua
>loading conditions. The ANSI driver also effects the overall throughput
>OV system.

I had only 2 partitons active, both were PCB and had default priority
abd the /PB since I don't want one node to get neglected when it is in
background! What kind of impact does the ANSI.SYS have on performance
and what should I do about it? Is there a way to set up OV so that both
partitions would get equal time if they were active, but if one was idle
it would give up it's time? That is similar to the way DV works.


Date: 09-14-89 (14:31)              Number: 138 / 572 (Echo)
  To: KEITH LUKEN                   Refer#: 137
From: DENNIS EDWARDS                  Read: NO
Subj: SPEED                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I had only 2 partitons active, both were PCB and had default priority
│abd the /PB since I don't want one node to get neglected when it is in
│background!

I wouldn't worry about it being starved of CPU time: These are, afterall,
interrupt driven processes.

>What kind of impact does the ANSI.SYS have on performance
│and what should I do about it?

ANSI sys is just another layer of code that your video output goes through.
There are a number of ANSI devices around and some are more efficient than
others. I don't have any benchmarks.

>Is there a way to set up OV so that both
│partitions would get equal time if they were active, but if one was idle
│it would give up it's time? That is similar to the way DV works.

The definition of "idle" has a lot to do with the answer. There are several
reasons why a program will "wait", as discussed in the App Notes. In most
cases a program that's waiting for something doesn't run. On a 386, any
program that handles a unique interrupt will be scheduled when that interrupt
occures; to that extent such programs will run even when they're waiting.

When you have multiple interrupt driven programs running then the efficiency
of the context switching mechanisms are highlighted - this is why I say that
you need to compare the system in a loaded condition to gain a meaningful
throughput expectation.

You might try turning on Topview emulation - some programs make keyboard
calls, etc., differently when they detect a TopView compatible multitasker
(such as DESQview). But, as I said the best thing to do is just go ahead and
use the default priorities - This will give you 50% response from the
foreground program and everybody else will split the rest of the time
(neglecting interrupt handler activity, etc.).

Date: 09-24-89 (17:10)              Number: 143 / 572
  To: DENNIS EDWARDS                Refer#: NONE
From: BOB HUNTER                      Read: 12-06-89 (11:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Well, Finally received Omniview! Have been playing around with it and
ran up against some problems.

1) I have a 386 with 4 megs using QEMM as the memory manager. I have
used the OV.BAT you listed here to start OMV. I load up the BBS system
(GAP) and all appears well. After a person calls in though it locks up
after a few screens. I have plenty of memory for the task (430K) and
have set the communications option.

Adding a DOS partition or other will create the problem even faster.
As GAP is similar to PCBOARD maybe someone out there could help.

I'll bet it is some simple thing I have overlooked!

PCRelay:CHEMEK -> Chemeketa OnLine [phone] Salem, OR

Date: 09-26-89 (14:47)              Number: 145 / 572 (Echo)
  To: BOB HUNTER                    Refer#: 143
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Well, Finally received Omniview! Have been playing around with it and
│ran up against some problems.
│
│1) I have a 386 with 4 megs using QEMM as the memory manager. I have
│used the OV.BAT you listed here to start OMV. I load up the BBS system
│(GAP) and all appears well. After a person calls in though it locks up
│after a few screens. I have plenty of memory for the task (430K) and
│have set the communications option.
│
│Adding a DOS partition or other will create the problem even faster.
│As GAP is similar to PCBOARD maybe someone out there could help.
│
│I'll bet it is some simple thing I have overlooked!
│
│PCRelay:CHEMEK -> RelayNet (TM)
│                  Chemeketa OnLine [phone] Salem, OR

Date: 09-26-89 (14:47)              Number: 146 / 572 (Echo)
  To: BOB HUNTER                    Refer#: 143
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│1) I have a 386 with 4 megs using QEMM as the memory manager. I have
│used the OV.BAT you listed here to start OMV. I load up the BBS system
│(GAP) and all appears well. After a person calls in though it locks up
│after a few screens. I have plenty of memory for the task (430K) and
│have set the communications option.
│
│Adding a DOS partition or other will create the problem even faster.
│As GAP is similar to PCBOARD maybe someone out there could help.

OMNIVIEW is designed to be used with 386^MAX - with many programs QEMM will
work fine, but in the case of interrupt driven processes residing in EMS,
appropriate context switching is not guaranteed. This may be your problem.

If I'm correct in assuming you're use of the menu shell then you _don't_ want
to have the "high speed communications" option set to yes. This is a "nice
thing" we included for users before the 386s were popular and interrupt
driven programs had to be nonswappable.  What you want to do is set "Runs in
background" and "Can swap to disk" to "Yes". Set "High Speed Communications"
to "No", you probably won't need to change any of the "Advanced Options" from
their default values. Set display type to "Text", or to one of the "xx lines"
options.

You want to make sure that you have "number of processes + 1" Alternate
Mapping Register Sets (AMRS) allocated by the memory manager. - with 386^MAX
this is done using an "AMRS=n" argument in the CONFIG.SYS file entry for the
memory manager. This will provide an adequate number of virtual EMS contexts
for task switching.

If you ran OVSETUP and selected "Expanded Memory Operation" for the menu,
then you need to run this program again and select "Standard Operation".
Expanded memory operation of the menu is where OVSHELL.COM runs in the page
frame and some programs (like Windows) don't like this. If you haven't
already done so you should "include" a 48K block of EMS and then edit the
second to last line of the OV.BAT file so that it starts with the word
OMNIHIGH instead of OMNIVIEW - this will significantly increase your
partition sizes by loading the multitasking kernal into upper memory. To
include the memory block on most systems (using 386^MAX) add
"INCLUDE=D400-E000" to the CONFIG.SYS file entry for the memory manager.

Date: 09-27-89 (13:02)              Number: 147 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 146
From: TRACY LEBENZON                  Read: 12-06-89 (11:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> with many programs QEMM will work fine, but in the case of interrupt
> driven processes residing in EMS, appropriate context switching is
> not guaranteed.

Actually, your statement is not at all accurate. QEMM-386 is designed
to support high speed interrupt driven communications. If the computer
is having problems, try increasing the number of tasks by use of the
"tasks=" command. The default number is 10. Additionally, if context
switching is a problem, use the "maps=" command. The default number
of maps is 8, which is sufficient for DV and 7 windows running in DV.

And, when you see the new version of QEMM-386...

Tracy Lebenzon

Date: 09-27-89 (21:23)              Number: 148 / 572 (Echo)
  To: BOB KRACK                     Refer#: NONE
From: RICK KUNZ                       Read: NO
Subj: R/O MSGS                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

->CALSTAR

 Bob: I have the OV files packed up and on their way to you with this
packet. You need to add r/o capability for yourself. Enter a message to
PCRELAY as a receiver-only message, with the subject ADD

This will add your r/o capability to your node. Are you running the beta
8 version of the node software?

Date: 09-28-89 (18:33)              Number: 149 / 572 (Echo)
  To: TRACY LEBENZON                Refer#: 147
From: DENNIS EDWARDS                  Read: 09-29-89 (11:20)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

 [ OMNIVIEW is designed to work with 386^MAX...]
│> with many programs QEMM will work fine, but in the case of interrupt
│> driven processes residing in EMS, appropriate context switching is
│> not guaranteed.
│Actually, your statement is not at all accurate....

The message I left regarded the design and operation of OMNIVIEW. The
statements I made regarding the reliabity of EMS context switches on
receipt of an IRQ are completely accurate.

To reliably run interrupt driven OMNIVIEW processes in EMS, you need 386^MAX.

Date: 09-29-89 (02:44)              Number: 153 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 146
From: BOB HUNTER                      Read: 12-06-89 (11:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> If I'm correct in assuming you're use of the menu shell then you _don'
> to have the "high speed communications" option set to yes. This is a "

Well, You are correct in the assumption on using the shell. I will try
the suggestions you have made this weekend. Sounds like they may be the
answer. Will look minto 386to the max, though I would hope that QEMM
will end up being OK after I learn more of the "Proper" operation of the
program.

I did note the speed from Omniview certainly appears to be faster than
DesqView. It will be interesting to see the differences (when I figure
Ominiview out a bit more). Thanks Dennis!!

PCRelay:CHEMEK -> Chemeketa OnLine [phone] Salem, OR

Date: 09-29-89 (06:07)              Number: 154 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 148
From: BOB KRACK                       Read: 09-30-89 (07:21)
Subj: R/O MSGS                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

->POVERTY
>packet. You need to add r/o capability for yourself. Enter a message to
>PCRELAY as a receiver-only message, with the subject ADD
>
>This will add your r/o capability to your node. Are you running the bet
>8 version of the node software?

Rick,
I have no idea what version I am using.  The EXEs are dated 5-13-89.

If I understand you correctly,
TO:PCRELY
SUB:xyz
SEC:R
ADD

The last week of my echoing from Mark, I lost a 60 meg drive containing
all of the documentation for PCRELAY.  I think I was using a newer
version of the code at that time, but it went with the drive and I
replaced with the only version I had backed up on floppy.  I haven't
wanted to bother you any more than absolutely essential, and it has been
working good, and I really didn't want system R/O so I just let it sleep
like that.

Perhaps it is time to ask you for the newer code and docs so I can
figger out just what I am really supposed to be doing?

Thanks,

      ^.B0B.^

PCRelay:CALSTAR -> CAL-STAR Communications [phone] 9600HST

Date: 09-30-89 (06:35)              Number: 156 / 572 (Echo)
  To: BOB HUNTER                    Refer#: 153
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Well, You are correct in the assumption on using the shell. I will try
│the suggestions you have made this weekend....

Good.

│Will look into 386to the max, though I would hope that QEMM
│will end up being OK after I learn more of the "Proper" operation of the
│program.

Let me know...

│I did note the speed from Omniview certainly appears to be faster than
│DesqView. It will be interesting to see the differences (when I figure
│Ominiview out a bit more). Thanks Dennis!!

You bet.

Date: 09-30-89 (13:42)              Number: 158 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: TRACY LEBENZON                  Read: 12-06-89 (11:31)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE> OMNIVIEW is designed to work with 386^MAX...

DE> with many programs QEMM will work fine, but in the case of interrupt
DE> driven processes residing in EMS, appropriate context switching is
DE> not guaranteed.

TL> Actually, your statement is not at all accurate....

DE> The message I left regarded the design and operation of OMNIVIEW.
DE> The statements I made regarding the reliabity of EMS context
DE> switches [in OMNIVIEW] on receipt of an IRQ are completely
DE> accurate.

DE> To reliably run interrupt driven OMNIVIEW processes in EMS, you
DE> need 386^MAX.

Oops. Well in that case, I guess your statement was accurate, but
mis-leading due to your use of English (or at least my interpretation
of it). Oh well. Thanks for the clarification.

Tracy Lebenzon


Date: 10-03-89 (00:33)              Number: 159 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: WILLIAM MUNSON                  Read: (N/A)
Subj: 386^MAX                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Is it possible to use the 386^MAX card in a XT type computer and still
get out of EMS operation?  I would like to run a 2 node bbs system at
lower baud rates ( 300 - 2400 ) but just cannot squeeze enough memory
out of a conventional memory setup even in the expert mode.  Thanks!

PCRelay:DATACOMM -> Data Comm - Rochester N.Y. 716-328-3844

Date: 10-05-89 (16:14)              Number: 160 / 572 (Echo)
  To: WILLIAM MUNSON                Refer#: 159
From: DENNIS EDWARDS                  Read: NO
Subj: 386^MAX                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Is it possible to use the 386^MAX card in a XT type computer and still
│get out of EMS operation?  I would like to run a 2 node bbs system at
│lower baud rates ( 300 - 2400 ) but just cannot squeeze enough memory
│out of a conventional memory setup even in the expert mode.  Thanks!

Unfortunately, to run '386 specific software such as 386^MAX you need a '386
based system. The costs of these systems, however, especially in the 16 bit
SX chip version are now reasonable: motherboards are available for about the
price of a LIM 4.0 board.

With LIM 4.0/EEMS hardware, a LIM 4.0 driver and a CGA it possible to get
two partitions of 300K+ on your current machine:

((736K max DOS space) - (Memory used by DOS) - (13K for OMNIHIGH))/2

Concurrent operation of larger interrupt driven processes will require a
'386.

Date: 10-06-89 (07:17)              Number: 161 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: 106blt.zip                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

106BLT.ZIP is available for file request or download from POVERTY or
from NETNODE. This is a text bulletin describing this conference and can
be used as a welcome screen.

Date: 10-07-89 (15:22)              Number: 162 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DUANE BAUMAN                    Read: 03-16-90 (17:36)
Subj: OMNIVIEW 4.13                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Received ver 4.13 and w/ 386max ver 4.03 dtd 12-23-88 omnihigh loads
OK but the pgm refused to stay up w/ a slowed down HST i.e 9600
used /s in two windows one /m:500 command other spawn m:220 /s /pb
telix.bat..... Tried reducing the memory size to m:220 on each
window and dropped the /s in both i.e. just in DOS killed the 386max
also and same problems modem would NOT run in background...Changed to
taskview ver 1.2 and works perfect. The machine is Mylex MI386-20
w/Award MY 3.04e BIOS.  Help Duane Bauman


Date: 10-08-89 (07:56)              Number: 163 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

After having Omniview and 386 Max sitting on the shelf for about 8
months,  I have decided to use it.  Finally got another line.  I am
having very similar problems to Bob Hunter.
I carefully read your message to Mr Hunter andam thoroughly confused
about a few things.  I tried the OMNIHIGH statement in the OV.BAT file
and get bad command name or file.  I have Omniview 4.01.  I have gone
through the 386 MAX docs and can fine no mention of the AMRS register
that goes in the config file.  Am I trying to run an outdated version of
both or what?
I;m basically new to this multitasking and really need some help.  I
would like to see batch files to call up my partitions, if possible.
I am running a 386 20mzh machine with a VGA adapter and 4 mgs of ems
memory.
One other question that I have and it is probably because I don't
understand how this works is, why if I have 4 megs of memory,
cant Omniview use some of this memory to load partitions.  Why are we
still limited to 640k.  Whats the purpose??
Hope I don't sound too stupid, but I guess I just don't understand it.


Date: 10-08-89 (09:49)              Number: 164 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: LATEST                        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

What are the latest versions of Omniview and 386 Max


Date: 10-06-89 (09:31)              Number: 165 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: KEITH LUKEN                     Read: (N/A)
Subj: OV & 386MAX FOR SALE          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have the most RECENT versions of 386-MAX and OMNIVIEW 4.13 for sale! I
no longer need them and am willing to let them go as a package for only
$75 ! It won't last at this great price! Leave me a message if
interested.


Date: 10-11-89 (07:01)              Number: 167 / 572 (Echo)
  To: DUANE BAUMAN                  Refer#: 162
From: DENNIS EDWARDS                  Read: 04-20-90 (18:48)
Subj: OMNIVIEW 4.13                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Received ver 4.13 and w/ 386max ver 4.03 dtd 12-23-88 omnihigh loads
│OK but the pgm refused to stay up w/ a slowed down HST i.e 9600

Install 386^MAX and include the AMRS=11 argument for it in CONFIG.SYS.
If this does not do it, leave me an R/O message with your voice number.

Date: 10-11-89 (10:04)              Number: 168 / 572 (Echo)
  To: JAMES WALL                    Refer#: 164
From: DENNIS EDWARDS                  Read: NO
Subj: LATEST                        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│What are the latest versions of Omniview and 386 Max

OV is currently at 4.13 while 386^MAX is at 4.07.

OV users may receive the current version by calling [phone].

Date: 10-11-89 (10:04)              Number: 170 / 572 (Echo)
  To: JAMES WALL                    Refer#: 163
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I tried the OMNIHIGH statement in the OV.BAT file
│and get bad command name or file. I have Omniview 4.01. I have gone
│through the 386 MAX docs and can fine no mention of the AMRS register
│that goes in the config file.  Am I trying to run an outdated version of
│both or what?

Yes. OV 4.01 did not include the OMNIHIGH program but, instead, used the
loadhigh function of 386^MAX. AMRS is not documented in the 386^MAX manual
but is mentioned in the README file on the current distribution disks.
SCREEN is undocumented.

│I would like to see batch files to call up my partitions, if possible.
│I am running a 386 20mzh machine with a VGA adapter and 4 mgs of ems
│memory.

If the expanded memory is on a plug in board, you should configure it as
extended memory and then use 386^MAX to convert that to virtual EMS. By
default, any memory left over after filling in the upper 384K and remapping
ROMs is converted to EMS. Once you have established virtual EMS you should be
able to use the batch files below.

D:\OMNIVIEW\>copy con START.BAT
OMNIHIGH /s /m:512 %COMSPEC% /c run.bat
^Z

D:\OMNIVIEW\>copy con RUN.BAT
spawn /s /m:512 %COMSPEC% /c load.bat
spawn /s /m:512 %COMSPEC% /c load.bat
%COMSPEC%
^Z

D:\OMNIVIEW\>copy con LOAD.BAT
REM: This batch file will start up your BBS (with the appropriate commands).
REM: The partition will close when the BBS exits since the shell is not
REM: reloaded at the completion of the .BAT files operation. To keep the
REM: partition open add '%COMSPEC%' as the last line if this file.
^Z

Once the batch files are created then, to start OV with 3 512K partitions (2
BBS nodes and a "large DOS" partition), you simply run START.BAT

You should be able to increase the size of the partitions above 500k; run
OVSTAT in the first partition and look at what it says your largest partition
size is, then substitute that value for the '/m' parameter values I've shown
here. With your system, you should have somewhere between 2M and 2.5M of EMS
remaining after these three processes are loaded.

│One other question that I have and it is probably because I don't
│understand how this works is, why if I have 4 megs of memory,
│cant Omniview use some of this memory to load partitions.  Why are we
│still limited to 640k.  Whats the purpose??

OMNIVIEW is a DOS multitasker. The purpose of all multitaskers is to load,
and concurrently run, partitions in EMS. With 386^MAX, OV partitions may also
run interrupt driven processes (aka: background communications). No DOS
multitaskers directly provide for the operation of individual processes which
are larger than the available Transient Program Area (TPA) though various
"DOS extenders" may be run inside OV partitions to provide this extra data
space for programs by operating in protected mode.

DOS programs must operate in either the 'REAL' or the 'VIRTUAL 8086' mode of
the system microprocessor: Each partition is limited in size to either the
amount of free RAM available beneath the video adapter(s) after OV is loaded
OR the amount of free EMS. With an EGA/VGA display the maximum partition size
will be something less than the resulting 640K TPA since DOS, resident
programs/device drivers and OV all take up some room in lower memory. The
available TPA with only an MDA/Hercules display is 704K or 736K with a CGA
only. OV will take up between 10K and 30K out of the TPA when loaded into
upper memory. The size of the largest available partition will be shown by
OVSTAT as the "largest free block" value on the third to the last line.

Since each process that is loaded on a '386 actually runs in EMS, each
program's use of EMS and each partition that is created will decrease the
available EMS. The currently available EMS is shown on the last line of the
OVSTAT display.

You may want to download the OVAPPN00.ZIP file (available on the "net") -
this is a collection of OV application notes which discuss the multitasker's
operation in much greater detail than space allows here. CONCURE.ZIP is also
available on the network - this is an "expert system" which will estimate a
systems performance under OV and includes the Memory application note.

Date: 10-13-89 (16:59)              Number: 172 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 170
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Thanks very much for the help Dennis. I have the latest versions of OV
and 386 Max on the way. As soon as they arrive I will try the bat
files. I will keep you informed to my progress and any problems that I
may have.


Date: 10-13-89 (20:14)              Number: 173 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 170
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>OMNIVIEW is a DOS multitasker. The purpose of all multitaskers is to lo
>and concurrently run, partitions in EMS. With 386^MAX, OV partitions ma
>run interrupt driven processes (aka: background communications). No DOS
>multitaskers directly provide for the operation of individual processes
>are larger than the available Transient Program Area (TPA) though vario
>"DOS extenders" may be run inside OV partitions to provide this extra d


       Dennis,  I ran the concure program and here are the results

Microprocessor is a 80386 running 11.98 times faster than a 4.77
EMM 4.0 driver is installed
640k of dos memory is installed while 544k of the TPA is free
System supports 47, 16k virtual EMS pages, provodong a max of 752k of
mappable EMS memory
3504k total of EMS memory is installed of which 2928k is free.
Number of alternate mapping registers is 0
Size of context save area is 94bytes
Number of DMA register sets is 0
Video filling would conflict with graphic adapters display memory.
THE EMS SYSTEM CONFIGURATION SUPPORTS CONCURRENT OPERATION OF -1
PROCESSES    !!What does this mean!!!
Current system allows multitasking of 8 540k processes.  144k of ems
would remin
Most tsr loaded in low memory could runb inside Omniview:   NEXT MESSAGE


Date: 10-13-89 (20:24)              Number: 174 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 170
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)



Now from this configuration.  Could I still run 2 partitions of
PCBoard??   What does that statement supports concurrent operation of -1
processes mean.   -1 that sounds strange.  Hope I don't sound too
stupid,  but I'm confused.


Date: 10-15-89 (08:29)              Number: 177 / 572 (Echo)
  To: JAMES WALL                    Refer#: 174
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Now from this configuration.  Could I still run 2 partitions of
│PCBoard??   What does that statement supports concurrent operation of -1
│processes mean.   -1 that sounds strange.

Yes, it does sound strange. Concure, I guess, needs to be revised. Both DOCs,
however, do talk about the need for allocating AMRS on a '386... Anyway, the
line below is the key to understanding this:

Number of alternate mapping register sets 0

What the -1 concurrent procs _means_ is that you have no AMRS=11 statement in
your 386^MAX line in the CONFIG.SYS. Concure "reasons" this way:

1) AMRSs are required for EMS context switching
2) Without context switching there can be no concurrent processes
3) The EMS on a '386 is presumed to be virtual
4) Virtual ARMSs needed are (number of procs + 1) = (10+1) = 11
Thus: concurrent procs possible is (number of AMRSs - 1) = 0-1 = -1

Add AMRS=11. Concure will say 10 and you should be up.

Date: 10-16-89 (06:01)              Number: 179 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: BOB HUNTER                      Read: 03-16-90 (17:36)
Subj: SETUP                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Wanted to let you know that I FINALLY got the system up and running with
two nodes and a couple of other processes. Not sure I would have been
able to figure it out without your help!

It is faster than the DV setup I was using, according to PCTOOLS System
Info - In a partition, under DV I would get a speed rating of 930-35%
over a PC - Now with OV, I get 1080-1090%. It shows in the response time
to users as well as in the partions I am running.

Now, If I can figure out why the LivePro door manager hung up last
night, I will have the whole thing set!

Appreciate all your help and want to commend your company for taking the
time and money to run this conference!

PCRelay:CHEMEK -> Chemeketa OnLine [phone] Salem, OR

Date: 10-17-89 (12:38)              Number: 181 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: concure revision              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

CONCURE, an "expert system" for evaluating a system's capability for DOS
multitasking, has been revised.  This revision only effects the information
displayed on an 80386 system with less than 11 AMRSs.  Previously, if AMRSs
were not allocated by the memory manager, CONCURE would display -1 for the
number of possible concurrent processes; a statement describing the need for
AMRS allocation is now displayed along with the number of processes that will
operate concurrently once the configuration has been changed.

The name of the revised file is CONCUR00.ZIP (41431 bytes) and includes a
.DOC file, an application note concerning memory usage by DOS multitaskers in
general, and a small file describing OMNIVIEW - the DOS multitasker from
Sunny Hill Software.

Date: 10-18-89 (07:38)              Number: 183 / 572 (Echo)
  To: BOB HUNTER                    Refer#: 179
From: DENNIS EDWARDS                  Read: NO
Subj: SETUP                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks.

Date: 10-20-89 (22:37)              Number: 184 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: OMNI                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hello Dennis,  I got the latest 386 MAX and Omniview ver 4.13.  Thanks
to your help I have Omniview up an running,  but I have a few problems.

When running Omniview from the command line. When I exit to dos from
the board I get the error: Invalid Command.com  Cannot start COMMAND,
exiting.  I get this error also if someone tries to enter a door and the
program exits to dos.
My run bat looks like this: spawn /s /m:512 %COMSPEC% /p:4
/D:SCR:NOWAIT,EGA /pb /c load.bat.

I am presently running with the menu interface.  I get and error here
also.  When a user enters Prodoor I get out of environment space errors,
altho the system continues to run properly.  I have the following in my
config.sys file.  shell=c:\command.com /p /e:2048.  Any help on both
problems will be greatly appreciated.

Date: 10-22-89 (09:09)              Number: 185 / 572 (Echo)
  To: JAMES WALL                    Refer#: 184
From: BOB KRACK                       Read: NO
Subj: OMNI                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>When running Omniview from the command line. When I exit to dos from
>the board I get the error: Invalid Command.com  Cannot start COMMAND,
>exiting.  I get this error also if someone tries to enter a door and th
>program exits to dos.
>My run bat looks like this: spawn /s /m:512 %COMSPEC% /p:4
>/D:SCR:NOWAIT,EGA /pb /c load.bat.

James,
If you are running PCBoard Version 14.1 or higher, those symptoms are
described by many in "plain jane" single application PC/MS-DOS. I have
the exact same problem running 14.1/E3 or 14.2/E3 as a single node
with NO multitasking and NO TSR's loaded.  Tried ramdisk for COMSPEC,
seemed to help a LITTLE.  Yes, the problem seems worst when PCBoard
"unloads" or shells to Prodoor.  Problem was the same with Prodoor
3.1b, 3.1 (registered or un-registered).  The incidence of "Unable
to load COMMAND" seemed to be SLIGHTLY lower if Prodoor was disabled.

>also.  When a user enters Prodoor I get out of environment space errors
>altho the system continues to run properly.  I have the following in my
>config.sys file.  shell=c:\command.com /p /e:2048.  Any help on both

There has been numerous mention in the Beta conference on Salt Air
and the shell size of 4096 has been suggested there.

I solved the problem here by running multiple events and doing a
warmboot at the end of each event, although drop to DOS between
calls and warmboot would be a better work-around for me.  I appreciate
the fact that I have not helped you to solve your problem, but mayhaps
I might have helped you look in more directions than one?


If it helps, my system is:
20 Mhz 286 with NEAT chipset  (MS-DOS 3.3 from Micro-soft, not OEM)
PCBoard 14.2 (beta)
Prodoor 3.1
RelayMail door
Procomm+
Files=21, Buffers=20, Device=Ansi.Sys
70 Meg ESDI drive (DOS partitioned)
2 floppies (1.2 and 360)
Single RS-232 w/961 HST
Monochrome (hercules)
Keytronics 101
and NO other hardware to have to search for conflicts.

I mention this ONLY to show the problem exists WITHOUT OmniView or
any of the SunnyHill software (in MY application).
Good luck!
      ^.B0B.^

PCRelay:CALSTAR -> CAL-STAR Communications [phone] 9600HST

Date: 10-24-89 (09:57)              Number: 186 / 572 (Echo)
  To: JAMES WALL                    Refer#: 184
From: DENNIS EDWARDS                  Read: NO
Subj: OMNI                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│When running Omniview from the command line. When I exit to dos from
│the board I get the error: Invalid Command.com  Cannot start COMMAND,
│exiting.  I get this error also if someone tries to enter a door and the
│program exits to dos.
│My run bat looks like this: spawn /s /m:512 %COMSPEC% /p:4
│/D:SCR:NOWAIT,EGA /pb /c load.bat.

First, there are problems with the displayed syntax of your SPAWN command
line - I'll assume that it is a typo and the '%COMSPEC%' actually appears
between the '/pb' and the '/c'. If this is not the case, please review the
syntax described in the manual. Keep in mind that %COMSPEC% is a batch
command and will only be expanded by the batch processor portion of the
command processor (shell). OV, OPEN and SPAWN will invoke COMSPEC to process
*.BAT files.

The only time that I have seen this problem come up (other than when the
COMMAND.COM file was corrupted/wrong version...) is when the shell spec and
comspec variable do not match and DOS thinks it is returning to the "parent"
('/p') command processor.  I am able to successfully 'shell out' and
run child programs under a variety of command processors using a number of
programs written by myself and others - so I don't see the problem
originating with OV.

│I am presently running with the menu interface.  I get and error here
│also.  When a user enters Prodoor I get out of environment space errors,
│altho the system continues to run properly.  I have the following in my
│config.sys file.  shell=c:\command.com /p /e:2048.  Any help on both
│problems will be greatly appreciated.

This is common problem with the environment of child processes resulting from
DOS' perception of the environment as a "read only" data structure. When DOS
creates a new environment block for a program it only allocates enough space
to hold the already defined variables (or 160 bytes, whichever is greater).

If you want to allocate more memory for a DOS partition's local environment
then you should add the '/e:nnn' parameter to each invocation of COMMAND.COM
which needs a large environment. While this will not directly effect the
space reserved for subsequent copies of the environment created _inside_ a
partition, it will allow you to define environment variables from a batch
file prior to running another program: This program would then inherit the
larger environment. It is possible that adding this argument to the command
processor could effect the first problem you described.

Date: 10-24-89 (20:18)              Number: 187 / 572 (Echo)
  To: BOB KRACK                     Refer#: 185
From: JAMES WALL                      Read: NO
Subj: OMNI                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>James,
>If you are running PCBoard Version 14.1 or higher, those symptoms are
>described by many in "plain jane" single application PC/MS-DOS. I have
>the exact same problem running 14.1/E3 or 14.2/E3 as a single node
>with NO multitasking and NO TSR's loaded.  Tried ramdisk for COMSPEC,



Thanks for the information. I have solved the Command.com problem. I
was using the /c parameter in the wrong place.
As far as the out of environment space message. I will try the 4096
parameter and see if it helps.


Date: 10-26-89 (20:14)              Number: 189 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: TONY CURRO                      Read: (N/A)
Subj: Multitasking                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

 Is this conference for the program called TASKview/Omniview from Sunny
Hill Software??
   I have a 286 with 6 meg of EXT or EXP mem. I cannot set my MB to
other than 640, so I cannot use DV.
  I am trying to find a program that will allow me to use ProComm plus,
U/l and D/l, while doing other work. Mostly all I would do besides
running PC+, would be formatting floppies, ZIPping or unZIPping files,
reading DOCs with Q EDIt. Stuff like that. Any help for me??
   I was thinking of ther ALLCHARGE card to be able to use DV. But don't
have the $$ right now. If I did I might as well have gotten a 386SX
board or even a reg 386 board for a few $$ more. Trying to do this as
cheaply as possible.
  THank you,
   Tony...


Date: 10-30-89 (08:14)              Number: 192 / 572 (Echo)
  To: TONY CURRO                    Refer#: 189
From: DENNIS EDWARDS                  Read: NO
Subj: Multitasking                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│ Is this conference for the program called TASKview/Omniview from Sunny
│Hill Software??

Yes. Welcome.

│   I have a 286 with 6 meg of EXT or EXP mem. I cannot set my MB to
│other than 640, so I cannot use DV.
│  I am trying to find a program that will allow me to use ProComm plus,
│U/l and D/l, while doing other work. Mostly all I would do besides
│running PC+, would be formatting floppies, ZIPping or unZIPping files,
│reading DOCs with Q EDIt. Stuff like that. Any help for me??

On anything less than a '386 you'll need to make you comm programs
non-swappable - so whatever size you give to your BBS partition will
"permanently" impact the space available for other processes. Within the
constraints of the remaining RAM, both processes will operate concurrently.

I am guessing, but if "EXT or EXP" means that the 6M of memory is on the
motherboard and configurable as either extended or expanded then most likely
it's only LIM 3.2 hardware - possibly with a LIM 4.0 driver. What I mean by
LIM 3.2 hardware is that it supports 4 physical EMS pages and no AMRSs. If
you have this type of hardware then OMNIVIEW will take up about 60K - 50K for
the kernal and 10K for the menu if it is loaded into the Page Frame.

We have written a program called CONCURE that will evaluate your system and
tell you what kind of performance you can expect from you hardware when
running OV. CONCUR00.ZIP (40K) is available from the network or from Rick
Kunz' BBS (Poverty Rock - [phone]).

If the EMS does provide several physical EMS pages then it can be used in two
ways: 1) OV can be loaded into an EMS block in upper memory saving about 30K
of DOS memory. 2) If you have a mono or CGA display adapter then the space
between 640K and the bottom of the adapters regen buffer can be filled in
with EMS expanding DOS memory by 64K or 96K respectively.

To determine the size of the second partition that you will have:
1) determine the current DOS free space.
2) subtract the OV overhead as described above (30-60K).
3) subtract the amount of memory you will need for the BBS (350-400K).
4) add the amount of memory added to DOS below the video adapters, if any.

You will probably end up with a second partition size in the range of
100-250K.

│   I was thinking of ther ALLCHARGE card to be able to use DV. But don't
│have the $$ right now. If I did I might as well have gotten a 386SX
│board or even a reg 386 board for a few $$ more. Trying to do this as
│cheaply as possible.

A '386 with 386^MAX is the way to go for multitasking if you can afford it.
The ALLCHARGE card will allow you to not backfill and do things like
spreadsheet recalcs, database sorts etc. in the background but interrupt
driven processes (BBSs) will still have to be non-swappable. On a 20MHz
'386sd, we handle about 100,000 IRQs a second (14,400 bps is about 2000/sec),
so even a 16MHz 386sx would probably handle your needs nicely.  Two 500K PCB
nodes and a DOS partition of equivalent size is obtainable on a 2M machine.

Date: 11-04-89 (23:12)              Number: 195 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: SHELL STATEMENT               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis,  I think I mentioned this to you once before but I didn't get a
reply.  I said that I keep getting these out of environment space errors
when a user goes into Prodoor.  I have the statement:
shell= c:\command.com /p /e:5096   in my config.sys file.   I have
absolutly no problems when I do not use Omniview and the three 512k
partitions.  As soon as I use Omniview I get the out of evvironment
space error.  This causes users not to be able to do Zip functions in
Prodoor.  The system just hangs,  I assume for lack of memory.
Increasing the memory size does not help.  It seems as though I should
put a shell statement in the partiton that the board is running in,
but I cannot seem to figure out how.  There is no provision in Omniview
that I know of to put a shell or device statement in partitions.  How
can I do it.  Please let me know and GIVE ME AN EXAMPLE.  Again I want
to thank you for all of your help

Date: 11-04-89 (23:26)              Number: 196 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: MORE                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I meant to mention in the previous message that increasing the size of
the shell does no good whatsoever.  HELP!!!!


Date: 11-06-89 (09:56)              Number: 197 / 572 (Echo)
  To: TONY CURRO                    Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: Multitasking                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│  Would you have a number for Sunny Sys. I have never seen TASKview
│advertised. I was wondering about cost and other info .etc.

The number for Sunny Hill is [phone]. OMNIVIEW is $79.95 retail,
sysops receive a 35% discount off the list price.

You may want to pick up CONCUR00.ZIP from the net'. This file contains, in
addition to a description of OMNIVIEW, an "expert system" for evaluating how
well you can expect OV to operate with your hardware: things like largest
free block, number of partitions, etc. will be displayed. If you can't get
the file through your home board you can download it (and a couple of other
OV related files) from Rick Kunz' Poverty Rock BBS at [phone] - this
board is a hub and 03:30 to 06:15 are reserved times for net traffic.

Date: 11-07-89 (10:23)              Number: 198 / 572 (Echo)
  To: JAMES WALL                    Refer#: 195
From: DENNIS EDWARDS                  Read: NO
Subj: SHELL STATEMENT               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis,  I think I mentioned this to you once before but I didn't get a
│reply.  I said that I keep getting these out of environment space errors
│when a user goes into Prodoor.  I have the statement:
│shell= c:\command.com /p /e:5096   in my config.sys file.
│... I get the out of evvironment
│space error.  This causes users not to be able to do Zip functions in
│Prodoor.

First of all, I'm sorry that you did not get my reply - I don't know what
happened to it, but here it is again:

DOS considers the environment to be a read only data structrure and,
accordingly, only allocates sufficient environment space to hold the defined
variables when a child process is created.  OMNIVIEW uses the DOS loader and
so the environment allocation is the same inside OMNIVIEW as in DOS. If
you want a secondary copy of the shell to provide a large environment you
must either define all the environment strings that you will need (possibly
with a dummy value of appropriate length) or else specifically allocate the
environment space for the child command processor.

The first method is best accomplished by a series of 'SET' commands in your
AUTOEXEC.BAT file.  The second method uses the same syntax as in the SHELL
command of CONFIG.SYS - which essentially defines the commands to invoke the
parent command processor.

To provide an equivalent environment size for a DOS partition using the
OV menu, set the 'Startup Command' field of the program form to:

c:\command.com /e:5096

Using the command line utilities to create a similar background DOS partition
would be accomplished with the following BATCH file command:

spawn /s ...  c:\command.com /e:5096

Note that using the second approach allows you to tailor the environment size
for each partition and so avoid what may be the unnecessary overhead of a
large parent environment.

Date: 11-10-89 (09:02)              Number: 202 / 572 (Echo)
  To: JAMES WALL                    Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: SHELL STATEMENT               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Thanks Dennis  Iwill give it a try.

You bet. Good luck.

Date: 11-17-89 (07:58)              Number: 204 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: displaying console number     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

CONSNUM, one of the utility programs supplied with OV, can be used in a batch
file to display the current partition number as part of the DOS prompt: The
batch file shown below demonstrates one way to do this. Remember to allow for
the increased environment size needed to establish the temporary variable and
to extend the prompt. Use the /e:nnn parameter to command.com either as part
of the open/spawn command line or as part of the "startup command" field in
the menu system.

ovprompt.bat

REM: Sets prompt to indicate current console number under OMNIVIEW.
REM: Requires DOS 3.3 or later.

goto start
:#10
set OVCN=0
goto done
:#09
set OVCN=9
goto done
:#08
set OVCN=8
goto done
:#07
set OVCN=7
goto done
:#06
set OVCN=6
goto done
:#05
set OVCN=5
goto done
:#04
set OVCN=4
goto done
:#03
set OVCN=3
goto done
:#02
set OVCN=2
goto done

:START
ECHO OFF
consnumb
if not errorlevel == 1 goto #10
if errorlevel == 11 goto err
if errorlevel == 10 goto #09
if errorlevel ==  9 goto #08
if errorlevel ==  8 goto #07
if errorlevel ==  7 goto #06
if errorlevel ==  6 goto #05
if errorlevel ==  5 goto #04
if errorlevel ==  4 goto #03
if errorlevel ==  3 goto #02
if errorlevel ==  2 goto #02
set OVCN=1

:done
SET prompt=-%OVCN%-%prompt%
:ERR
SET OVCN=

Date: 11-28-89 (13:55)              Number: 207 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: any suggestions?              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I think this conference is of value to OV users and the message base contains
several remarks which confirm this. I am looking for topics of discussion
which I can _initiate_ here. I recently posted a batch file illustrating a
"novel" application of CONSNUMB - has anyone used this? A couple things that
I could do are present some of the Application Notes in a message format or
maybe start a tutorial on the API.  There are a couple hundred messages which
have been sent through this conference and many of these cover similar topics
- should I edit these and start a Q&A series?

What would you like to see?

Date: 11-29-89 (01:13)              Number: 208 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 207
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: ANY SUGGESTIONS?              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>maybe start a tutorial on the API.  There are a couple hundred messages
>have been sent through this conference and many of these cover similar
>should I edit these and start a Q&A series?

That might be a good approach for starters, Dennis -- a
"Most-frequently-asked Questions" series or somethine. Also, I'd like to
see you repost information on the series of files you have uploaded;
CONCUR00.ZIP is one more people should know about, and the ability to
call up OV from batch is of particular interest to me, and I'm sure many
others.

I'll "recruit" a little in a couple other conferences, too. :-)

Date: 11-29-89 (15:29)              Number: 209 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 207
From: JAMES WALL                      Read: 03-16-90 (17:36)
Subj: any suggestions?              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>which I can _initiate_ here. I recently posted a batch file illustrati
>"novel" application of CONSNUMB - has anyone used this? A couple thing
>I could do are present some of the Application Notes in a message form
>maybe start a tutorial on the API.  There are a couple hundred message
>have been sent through this conference and many of these cover similar
>- should I edit these and start a Q&A series?

Yes Dennis,  I think that would be a GREAT!!  idea.


Date: 12-01-89 (16:55)              Number: 212 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes:  Vol 1, #1     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Starting up OMNIVIEW with mulitple active partitions from the DOS command
line is a simple, if somewhat tedious, task. During the next few days I'll
present (or reintroduce) a series of batch files that will make this task
even easier. Since these files are simply designed to illustrate the steps
involved in spawning multiple process, they will probably not serve you
perfectly as they stand. They should, however, provide you with a usable
framework which you can tune to meet your various needs.

Once I've finished the presentation of these little utilities, I will
upload them in a packet to Poverty Rock where they (along with this
text) will be accessible from the network.  At that time I will
present a summary of all OV related files on 'the Rock'.

The time that I will take for this presentation will allow you to cast
your votes for any specific topics that you would like to see covered
here.  It will also allow me to download and begin editing the
existing message base into the Q&A format that you have requested.  If
there is something that you need help with during these presentations,
by all means speak up.

I (, too,) have some qualms about my role as a columnist. I do think,
though, that the editorial approach does have some advantages:  Among
those are the facts that this will smooth out the message traffic here
and allow you to experiment with and respond to the smaller chunks of
information that will be presented.  Since we will be dealing with
specific aspects of OMNIVIEW and/or DOS in each 'installment' it will
also allow me to cover these topics in greater detail than I might
when responding to a tech support request.  Such requests often entail
a discussion of several related aspects of the PC and are
appropriately limited to a single message.

So those are my immediate plans for this conference - and I've
certainly spent enough time talking about them.  In my next set of
messages, I will present a batch file which I use nearly every day to
bring up OMNIVIEW with a variably sized DOS partition.

Date: 12-01-89 (16:55)              Number: 213 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes:  Vol 1, #2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

When you type 'OMNIVIEW' at the DOS command line and hit enter you get
the menu.  To load something else (like a DOS partition) into the
initial partition, you must tell OMNIVIEW what you want to run inside
that parition.

OMNIHIGH, OMNIVIEW, SPAWN and OPEN all take a common set of parameters
that determine the size and scheduling or device characteristics of
the partition the program will create.  All of these parameters are
documented in the manual - so we won't dwell on them now.  The point I
want to make is this: When any of these programs comes across an
argument which it does not recognise it assumes the argument to be a
program name.  Any subsequent arguments are assumed to be arguments to
the supposed 'child' program rather than to OMNIHIGH, OMNIVIEW, SPAWN
or OPEN.

To create a partition that runs a program other than the menu, all we
need to do is type in that program's name and its arguments just as we
would at the DOS prompt. The only difference here is that the the name
of another program and its arguments must come before the name of the
program we want to run.

To create a 'DOS' partition, we want to run a program that will take
some input from us, pass that input on to DOS in a format that DOS
will understand and reload itself as neccessary to repeat the process.
On most PC systems this program is called COMMAND.COM.  Many people
assume COMMAND to _be_ DOS - but it ain't. COMMAND is simply a program
bundled with DOS to processes console (and batch) input.  Because of
what it does, COMMAND is one of a class of programs called command
processors (or shells).  A shell does four things:

    1) It gives you something to look at (the prompt).
    2) It gives you something to do (it reads console input).
    3) It processes internal commands (which include those
       commands associated with Batch files).
    4) It assumes that anything it doesn't understand is the name
       of a program. The shell will always pass on unknown
       arguments to the OS which will try to run it.  This is the
       basis for the wording of the 'Bad command or file name.'
       error message.

Whenever DOS doesn't have anything better to do it loads the command
processor. If you don't tell it otherwise, DOS will run COMMAND
whenever a shell is called for.  However, there are programs which
improve on COMMAND's capability and many people choose to use one of
these other shells.  4DOS, Command Plus and various 'Unix' shells are
in this product catagory.  Most of these alternate shells can be run
under or on top of COMMAND and all of them must, to some extent, work
like COMMAND.  The shell which is loaded initially is known as the
'primary' command processor. Any shell which is loaded _by_ the
primary command processor is called a 'secondary' command processor.

COMMAND (and all compatible command processors) have two parts, one is
called the 'transient' part and the other is known as the 'resident'
part. Like most TSRs, COMMAND's transient part contains the user
interface code and is over-written by other programs which run after
it.  The resident part of command is what keeps the computer "alive"
and often (though not always) is only loaded into memory once.  The
transient portion of COMMAND is constantly being loaded, and reloaded
as you start up and exit from application programs. When you 'shell to
DOS' from an application program you are invoking a secondary command
processor.

To over-ride DOS' assumption that you want to use COMMAND as your
primary shell (or to modify this shell's default behavior) you must
include a 'SHELL=' statement in your CONFIG.SYS file.  The SHELL
statement tells DOS the name and location of the desired primary
command processor. In the case of COMMAND it also includes some
arguments that alter the behavior of the command processor.

The arguments taken by COMMAND are assumed by some to apply only to
the SHELL statement of CONFIG.SYS. In fact all the parameters
associated with the SHELL statement are only processed by COMMAND and,
with the exception of '/p' (which causes AUTEXEC to be run and
inhibits the EXIT command), these parameters may be applied any
time that the program is run.  The '/c' parameter tells COMMAND that
it should run a program and then unload itself completely from memory.

The '/e' parameter tells COMMAND the _minimum_ amount of memory it
must reserve for environment variables. A common misconception is that
this environment block is fixed to the size specified by the '/e'
parameter. In fact, the environment can be freely expanded to any
arbitrary length up to 32,768 bytes up until another memory block is
allocated by DOS; at this point the environment _does_ become fixed
at either the value specified for '/e' or the space required to house
the existing strings, whichever is greater.  Running any program,
including a Batch file will cause memory to be allocated, fixing the
size of the environment.  The only way to freely expand it is by
console input to the command processor, avoiding external and batch
commands until the environment has reached the desired size.

Date: 12-01-89 (16:55)              Number: 214 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes:  Vol 1, #3     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

When DOS needs to reload the shell's transient part, it looks in the
environment for the COMSPEC variable (short for COMmand processor
SPECification) and executes the program (passing it any arguments)
named in that string.  IF you don't specify a value for the COMSPEC
variable, DOS assigns it the name and location of the shell specified
in CONFIG.SYS (or [boot drive]:\COMMAND.COM, by default).  COMSPEC
does not over-ride the PATH, when running a shell directly, DOS looks
for it only in the directories listed in the PATH variable (and, of
course, in the current or any specified directory).

If you specify COMSPEC (without preceeding it with SET) in your
AUTOEXEC.BAT file, any parameters to the shell will be ignored. If you
specifically 'SET' the value of COMSPEC, however, then any desired
arguments will be passed on to the shell when COMSPEC is invoked as a
command. Using 'SET COMSPEC=' along with '/e:nnn' in your
AUTOEXEC.BAT file is one way to insure that you have sufficient
environment space in all your OMNIVIEW partitions.

You should be aware that each program handles environment strings
differently and the above alteration of COMSPEC may confuse some
programs enough that they may not run correctly. Consequently, a
safer approach is to create a new environment variable (say ENVSZ)
that holds the desired size of your environment.  This new variable
may be used in a Batch file to specify the environment size allocated
by a shell.

Since memory is a precious commodity, you should remember that
expanding the environment and using alternate shells always takes up
memory that might be used by another program.

If you use 4DOS, for instance, the smallest DOS partition that you can
have is somewhere around 60k in size. While most of this space (about
45-50K) is available to run other programs, the size of 4DOS'
transient portion is significantly larger than that of COMMAND and
this accounts for the larger partition size requirement.  If you only
want to load a shell to run a batch process or do simple tasks, it may
be worth your while to use COMMAND for these purposes and reserve a
single 'DOS' partition for the alternate shell.

Reaching a decision about how to expand the environment is a little
more complicated.  The following facts need to be considered:

    1) Your '/e' argument in the SHELL statement of a CONFIG.SYS
       file is no different from any other '/e' argument given to
       a 'secondary' copy of COMMAND.
    2) The '/e' argument to COMMAND tells it to allocate a
       specific amount of memory, along with its resident portion,
       for storing environment variables. If no '/e' parameter is
       used a default environment size of 160 bytes is allocated.
       The environment size of each shell may be different.
    3) The size of the environment is always rounded up to the
       next multiple of 16 bytes to insure that subsequent memory
       allocations are 'paragraph aligned'.
    4) _ONLY_ those strings which are currently defined in the
       environment are passed to programs executed from the
       command line.  Any extra space in a program's copy of the
       enviroment is due to the memory alignment mentioned above.
    5) Environment variables are ASCIIZ strings meaning that they
       are 'teminated' by a byte with an ASCII value of zero.
       This byte is not visible but must be included when
       computing the space taken up by an individual environment
       variable (along with the '=' and all spaces and/or tabs).

If you set the environment size using the COMSPEC environment variable
then each time a shell is loaded using comspec it will have a memory
cost of:

    (actual environment size - 160) bytes.

If you create a large initial environment and define a long series of
environment variables then _each program that is loaded_ will inherit
those environment strings, regardless of whether they are used.  The
cost of this approach, of course, varies with the number and size of
the environment strings.  When you have a program that requires
several environment variables to be defined it will, undoubtedly, be
expensive.

Date: 12-01-89 (16:55)              Number: 215 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes:  Vol 1,#4      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The approach to managing the environment that I recommend acounts for
each of the factors above and it provides flexibility in establishing
the environment while minimizing its impact on available memory.  The
process is this:

    1) Determine the minimum string space you need to accomplish
       the majority of your work. If you have one or two programs
       which will be loaded into a partition and that eat lots of
       environment space, leave them out of this calculation.
    2) Supply the environment size determined above to the SHELL
       statement in your CONFIG.SYS file. If your programs don't
       choke on it, you can also add this argument to the 'SET
       COMSPEC=' statement in your AUTOEXEC.BAT file, otherwise
       create an environment variable to holds this value.
    3) Define your most commonly used environment strings.
       Sometimes you will need to define various environment
       variables different values, as when changing a compilers
       'include' directory for different projects.  From a memory
       efficiency stand point, it is better to create a batch file
       which changes these variables than to define all possible
       strings.
    4) For each program that requires a larger environment,
       determine their individual allocation needs. Create a Batch
       file for each of these programs which sets COMSPEC to the
       desired shell and modifies your environment size variable
       to indicate the appropriate environment size. It is not a
       bad idea to create scratch environment variables in
       these batch files which hold the original variable's values
       so that they can be restored once the process is created.
    5) When you need to create a partition with a large
       environment, simply load a copy of the shell using a
       command line (or Startup Command string in the menu) that
       specifies the new environment size.

So now, with all this background out of the way, we can finally look
at The Batch File.


                 OMNIDOS.BAT

Takes one more arguments and creates an appropriate initial OMNIVIEW
'DOS' partition.  The order of the arguments to OMNIDOS are important,
these arguments are:

    1) Number of K-bytes to allocate for the partition.
       The argument must always be specified.
    2) Arguments to OMNIVIEW/OMNIHIGH. All these arguments must be
       listed without any intervening white space. This argument
       is required if a Batch file is to be run in the initial
       partition.
    3) Name of a Batch file to run in the initial partion, if any.
    4) Arguments to the above batch file, if any.

Example:

d:>OMNIDOS 400 /s/d:scr:50 wakeup.bat coffee.exe bacon.com waffles.bat

Notes:
    - Assumes presence of LIM 4.0 EMS system (uses OMNIHIGH).
    - Calls OVERRLVL.BAT to print a message describing the
      error code returned when OV exits.
    - Partition will close when the batch file concludes unless
      the transient portion of the command processor is
      specifically reloaded.
    - The second argument could be 'hardcoded' into the batch file.


REM: OMNIDOS.BAT
ECHO OFF
if not '%1'=='' goto TEST_FOR_A_PROGRAM
ECHO OD.BAT: Must specify an initial partition size
goto DONE

:TEST_FOR_A_PROGRAM

c:
cd\ov

if not '%3'=='' goto RUN_A_PROGRAM
omnihigh /m:%1 %2 %COMSPEC% %ENVSZ%
goto DONE

:RUN_A_PROGRAM
omnihigh /m:%1 %2 %COMSPEC% %ENVSZ% /c %3 %4 %5 %6 %7 %8 %9

:DONE
call    overrlvl.bat

Date: 12-06-89 (11:41)              Number: 217 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes: Vol 1, #5      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

In the OMNIDOS.BAT file we developed a fairly flexible way to start up
OMNIVIEW with a DOS partition (possibly running a batch file or an
application program).  OMNIDOS.BAT ended with a 'call' to
OVERRLVL.BAT.  The purpose of this Batch file is to test for the
various error codes returned by OMNIVIEW when it dies.  The error
codes are a superset of the conventional MS/PC-DOS extended error
codes.  While this batch file doesn't take any parameters, the call
to OVERRLVL.BAT must be made before another program is run or the
error level will not reflect OMNIVIEW's exit status.

There are a lot of error levels to test in OVERRLVL.BAT so I have
broken up the tests into four groups in an attempt to improve its
performance.  I don't guarantee that this is an optimum solution but
it is a little quicker than a sequential test of each error level,
especially for the smaller (and most common) error code values.  If
you have a better way, please let the rest of us know about it.  With
OMNIVIEW version 4.13, OMNIHIGH will only return error levels of 1 and
0.  This is being fixed.

Date: 12-06-89 (11:41)              Number: 218 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: overrlvl.bat - part 1         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

ECHO OFF
REM: This file will display a message describing the OMNIVIEW exit
REM: status.

if errorlevel 1 goto ERRBRANCH
echo OMNIVIEW: Normal exit.  No processes running.
goto DONE
:ERRBRANCH
if errorlevel 103 goto ERRBAD
if errorlevel 90 goto ERR102
if errorlevel 80 goto ERR89
if errorlevel 19 goto ERRBAD
if errorlevel 10 goto ERR18
goto ERR9
:ERRBAD
if errorlevel 255 goto DONE
echo OMNIVIEW: Unknown error.
goto DONE
:ERR102
if not errorlevel 102 goto ERR101
echo OMNIVIEW: Semaphore is set.
goto DONE
:ERR101
if not errorlevel 101 goto ERR100
echo OMNIVIEW: Exclusive semaphore already owned.
goto DONE
:ERR100
if not errorlevel 100 goto ERR95
echo OMNIVIEW: Too many semaphores.
goto DONE
:ERR95
if errorlevel 96 goto ERRBAD
if not errorlevel 95  goto ERR93
echo OMNIVIEW: System call interrupted.
goto DONE
:ERR93
if errorlevel 94 goto ERRBAD
if not errorlevel 93  goto ERR92
echo OMNIVIEW: No items found to work on.
goto DONE
:ERR92
if not errorlevel 92  goto ERR91
echo OMNIVIEW: Timer service table duplicate.
goto DONE
:ERR91
if not errorlevel 91  goto ERR90
echo OMNIVIEW: Timer service table overflow.
goto DONE
:ERR90
echo OMNIVIEW: Not frozen error.
goto DONE
:ERR89
if not errorlevel 89  goto ERR88
echo OMNIVIEW: No process slots available.
goto DONE
:ERR88
if not errorlevel 88  goto ERR87
echo OMNIVIEW: Network write fault.
goto DONE
:ERR87
if not errorlevel 87  goto ERR86
echo OMNIVIEW: Invalid parameter.
goto DONE
:ERR86
if not errorlevel 86  goto ERR85
echo OMNIVIEW: Invalid password.
goto DONE
:ERR85
if not errorlevel 85  goto ERR84
echo OMNIVIEW: Already assigned.
goto DONE
:ERR84
if not errorlevel 84  goto ERR83
echo OMNIVIEW: Out of structures.
goto DONE
:ERR83
if not errorlevel 83  goto ERR82
echo OMNIVIEW: Interrupt 24 failure.
goto DONE
:ERR82
if not errorlevel 82  goto ERR81
echo OMNIVIEW: Cannot make item.
goto DONE
:ERR81
if not errorlevel 81  goto ERR80
echo OMNIVIEW: Duplicated FCB error.
goto DONE
:ERR80
echo OMNIVIEW: File already exists.
goto DONE

<continued...>

Date: 12-06-89 (11:41)              Number: 219 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: overrlvl.bat - part 2         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


:ERR18
if not errorlevel 18 goto ERR17
echo OMNIVIEW: No more files.
goto DONE
:ERR17
if not errorlevel 17  goto ERR16
echo OMNIVIEW: Not same device.
goto DONE
:ERR16
if not errorlevel 16  goto ERR15
echo OMNIVIEW: Current directory error.
goto DONE
:ERR15
if not errorlevel 15  goto ERR13
echo OMNIVIEW: Invalid drive.
goto DONE
:ERR13
if errorlevel 14 goto ERRBAD
if not errorlevel 13  goto ERR12
echo OMNIVIEW: Invalid data.
goto DONE
:ERR12
if not errorlevel 12  goto ERR11
echo OMNIVIEW: Invalid access.
goto DONE
:ERR11
if not errorlevel 11  goto ERR10
echo OMNIVIEW: Bad format error.
goto DONE
:ERR10
echo OMNIVIEW: Bad environment.
goto DONE
:ERR9
if not errorlevel 9 goto ERR8
echo OMNIVIEW: Invalid block.
goto DONE
:ERR8
if not errorlevel 8 goto ERR7
echo OMNIVIEW: Not enough memory.
goto DONE
:ERR7
if not errorlevel 7 goto ERR6
echo OMNIVIEW: Memory arena trashed.
goto DONE
:ERR6
if not errorlevel 6 goto ERR5
echo OMNIVIEW: Invalid handle.
goto DONE
:ERR5
if not errorlevel 5 goto ERR4
echo OMNIVIEW: Access denied.
goto DONE
:ERR4
if not errorlevel 4 goto ERR3
echo OMNIVIEW: Too many open files.
goto DONE
:ERR3
if not errorlevel 3 goto ERR2
echo OMNIVIEW: Path not found.
goto DONE
:ERR2
if not errorlevel 2 goto ERR1
echo OMNIVIEW: File not found.
goto DONE
:ERR1
echo:
echo OMNIVIEW: Invalid function.
:DONE

Date: 12-06-89 (11:41)              Number: 220 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes: Vol 1, #6      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Once we have created a DOS partition we can use SPAWN and/or OPEN to
create 'sibling' processes from a Batch file.  By making use of the
alternate syntax of OMNIDOS.BAT and specifying a Batch file as the
program argument, we can have the processes created automatically as
part of OMNIVIEW's startup procedure.

One way to automate process creation is illustrated in SPAWNONE.BAT.
SPAWNONE inherits its arguments from the command line used to start up
OMNIVIEW and uses these values to create a second partition.  SENDKEYS
is used to 'type' commands into the second partition that alter the
prompt and then execute a program.

The last thing that SPAWNONE.BAT does is to call OVPROMPT.BAT and then
reload the transient portion of the shell so that the first partition
remains operationally. With out this last step, the partition would
close itself out when the shell died on completion of the Batch file -
this is part of the behaviour implied by the '/c' switch of
COMMAND.COM.  If you wanted the OMNIVIEW menu to be active in the
initial partition simply make the first partition about 60K and
replace %COMSPEC% with OVSHELL in the last line of the OMNIDOS file.

SPAWNONE could be modified in a number of ways to create more than
process.  The most obvious way is just to 'hard code' a series of
SPAWN and SENDKEYS commands to start up arbitrary applications.  A
more flexible approach would be to create FOR loop that would process
a series of command line arguments.  By using mulitple SHIFTs, the
same code could be used to create different processes based on
variable OMNIVIEW command line arguments. If you create such a batch
file (or have an even better solution), please post it so we can all
take a look.

Date: 12-06-89 (11:42)              Number: 221 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: spawnone.bat                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

ECHO OFF
REM: SPAWNONE.BAT
REM:    When run from the OV command line, this starts up a second DOS
REM:    process, sets the prompt in each partition to indicate the console
REM:    number of the process, and runs a program in the second partition.
REM:
REM: Usage:
REM:    SPAWNONE.BAT proc_size spawn's_args program_to_run program's_args...

if not '%1'=='' goto GO
waitkeys ' ','SPAWNONE.BAT: No process size specified. Hit the space bar',10
goto DONE

:GO
spawn /m:%1 %2 %COMSPEC% %ENVSZ%
sendkeys 2 ovprompt\r
sendkeys 2 %3 %4 %5 %6 %7 %8 %9\r

call ovprompt
%COMSPEC%

Date: 12-08-89 (09:10)              Number: 222 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes:  Vol 1, #7     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

SPAWNONE.BAT employed SENDKEYS and CALL to execute an OVPROMPT.BAT
file. This Batch file changes the DOS prompt to indicated the console
number of the partition.  This console number is returned in error
level by CONSNUMB. OVPROMPT does a series of tests on the CONSNUMB
exit code and sets a temporary environment variable to the ASCII value
of the console number.  This temporary variable is incorporated in a
PROMPT command and then removed from the environment to reclaim the
space it took up.

The reason that we go to all this trouble is that errorlevel can't be
processed directly as part of a command line argument, only the
actual batch parameters and environment variables can. Since DOS
provides no way of altering the values of Batch variables, environment
variables become our only option.

While you may not care to alter the DOS prompt, OVPROMPT's method of
'trapping' a program's error level can still be useful since SPAWN and
OPEN both return the console number of the new process (or 255 on
error). Creation of a temporary environment variable holding the new
process' console number can be employed as an argument to SENDKEYS;
this allows processes to be created with uniform arguments regardless
of the number of sibling processes. Those of you who may be building
a universal loader Batch file may find use for this trick, please
show us if you do.

Date: 12-08-89 (09:10)              Number: 223 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: ovprompt.bat                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

ECHO OFF
goto start
:#10
set OVCN=0
goto done
:#09
set OVCN=9
goto done
:#08
set OVCN=8
goto done
:#07
set OVCN=7
goto done
:#06
set OVCN=6
goto done
:#05
set OVCN=5
goto done
:#04
set OVCN=4
goto done
:#03
set OVCN=3
goto done
:#02
set OVCN=2
goto done
:START
consnumb
if not errorlevel == 1 goto #10
if errorlevel == 11 goto err
if errorlevel == 10 goto #09
if errorlevel == 9  goto #08
if errorlevel == 8  goto #07
if errorlevel == 7  goto #06
if errorlevel == 6  goto #05
if errorlevel == 5  goto #04
if errorlevel == 4  goto #03
if errorlevel == 3  goto #02
if errorlevel == 2  goto #02
set OVCN=1
:done
SET prompt=-%OVCN%-%prompt%
:ERR
SET OVCN=

Date: 12-08-89 (09:10)              Number: 224 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: DOS Processes:  Vol 1, #8     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The final batch file I'll present in this series is one which starts
up OMNIVIEW and uses all the techniques we've been discussing.
TESTTWO.BAT illustrates how you can build task specific OMNIVIEW work
environmnets with a single DOS command.  All that is required is that
you alter TESTTWO (and possibly SPAWNONE) to reflect the desired
program information.

Each of the Batch files, along with the combined message text in this
series, is being uploaded to Poverty Rock in a file called
OMNIDOS1.ZIP.  This file contains:

    TESTTWO.BAT - a sample batch file illustrating how to
        start up OMNIVIEW with a specific combination of
        programs.

    OMNIDOS.BAT     - a batch file that creates an initial DOS
        partition and optionally runs a program inside that
        partition.

    OVERRLVL.BAT    - a batch file that displays a message
        describing OMNIVIEW's exit status.

    SPAWNONE.BAT    - a batch file that, when run in the first
        partition creates a second partition and optionally
        runs a program inside that partition.

    OVPROMPT.BAT    - a batch file that alters the DOS prompt to
        indicate a partitions console number. Illustrates
        setting an environment variable to indicate
        errorlevel.

    DOSPROCS.TXT    - the text of series of RelayNet messages that
        comprise a tutorial on the creation of multiple DOS
        processes using OMNIVIEW.

Date: 12-08-89 (09:10)              Number: 225 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: TESTTWO.BAT                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

ECHO OFF
REM:  TESTTWO.BAT
REM:    This file uses the OMNIDOS, SPAWNONE, OVERRLVL and OVPROMPT batch
REM:    files as well as SPAWN, WAITKEYS and SENDKEYS to illustrate how multip
REM:    processes can be loaded from the DOS command line.  Note that ENVSZ is
REM:    set the default value of 160 bytes.

set envsz=/e:160
omnidos 500 /s spawnone 500 /s cd\\\rdir/w

Date: 12-08-89 (09:10)              Number: 227 / 572 (Echo)
  To: SYSOPS                        Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: Roll Call                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Howdy.

I often talk with people in tech support who do not know about RelayNet but
who are interested in logging on for this conference and the files we have
presented.  Unfortunately, I have not accumulated a list of boards that are
carrying this conference. I do have the Official RelayNet Node List but...

Please respond with a short description of your board if you are carrying
this conference (access restrictions, fees (if any), board focus,
bauds, hours of operation, etc.).  You know the drill.

Thanks.  I'll do what I can to reciprocate your support.

Date: 12-10-89 (09:28)              Number: 232 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 227
From: BOB HUNTER                      Read: 03-16-90 (17:36)
Subj: Roll Call                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

We're still here, Dennis!

Chemeketa OnLine
Bob Hunter SYSOP
Salem, OR
[phone]
24 hrs
HST 14.4 All bauds OK
Running GAP 4.3/M

BBs sponsered by Chemeketa Community College.

PCRelay:CHEMEK -> Chemeketa OnLine [phone] Salem, OR


Date: 12-13-89 (07:44)              Number: 235 / 572 (Echo)
  To: BOB HUNTER                    Refer#: 232
From: DENNIS EDWARDS                  Read: NO
Subj: Roll Call                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│We're still here, Dennis!

Thanks, Bob.

Date: 12-13-89 (09:23)              Number: 236 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: MARC GOLDSCHMITT                Read: (N/A)
Subj: OMNIVIEW WITH PCBOARD         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have followed the instructions in the BOARD manual, but I must
be missing something...I have loaded OMNIVIEW. I have checked the
status of memory using the OMNISTAT, and it shows that I have 439K
available for programs. When I put in the PCBOARD program, I have
specified that it takes 220K "required" memory (per instructions)
with 220K "desired" with expanded memory at 0K (on this system,
there is only basic 640K RAM). I have set elements such that there
is no swapping to disk, high speed com, graphics, does not write to
video RAM. I have set the config.sys files for the files and buffers
settings recommeded, and  have installed SHARE. Yet when I try to load
the system, OV says that I do not have enough memory! I am using DOS
v3.3 on a COMPAQ 286.

PCRelay:BYPASS -> RelayNet (tm)
                  Springfield Bypass (703)-941-5815  USR-HST

Date: 12-20-89 (07:49)              Number: 248 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: BOB HUNTER                      Read: 03-16-90 (17:36)
Subj: OV conference                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis - Keep Chemeketa on your list - We are here!

Bob Hunter

PCRelay:CHEMEK -> WESTNET + msgs Copyright 1989 by author
4.10ß9            Chemeketa [phone] Salem, OR - HST DUAL

Date: 01-01-90 (01:26)              Number: 253 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: CRAIG DUCHARME                  Read: 03-16-90 (17:36)
Subj: QEMM OR 386MAXPRO             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

    Dennis,
I was told that your the pro at expanded memory and I could use a hand.
The generic DOS sector expanders require A000 to be accessable to run.
My memory board won't let this happen.  Is this going to be a problem
for QEMM or 386MAX?  Also which multi-tasking program do you like if ou
were going out and getting one tommarow.  Hope you can help me out with
this.  I'm running an Intel 386 at 25Mhz with 4Mb or ram and I like my
TSR's allthough I've been doing without.
               Thanks Craig Ducharme

Date: 01-04-90 (08:39)              Number: 254 / 572 (Echo)
  To: CRAIG DUCHARME                Refer#: 253
From: DENNIS EDWARDS                  Read: NO
Subj: QEMM OR 386MAXPRO             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│The generic DOS sector expanders require A000 to be accessable to run.
│My memory board won't let this happen.  Is this going to be a problem
│for QEMM or 386MAX?

I'm not sure that I understand what you mean by 'sector expanders' but I'll
assume that your talking about the EMM emulators that use expanded memory in
real mode. The big difference is that the EMM emulators switch between
protected and real mode while 386Max and QEMM operate in virtual 8086 mode.

If you have a VGA/EGA display system (or other high resolution system - such
as the "full page" mono display adapters), there will still be a memory
conflict that would arise by mapping in EMS to the A000h segment - even with
386Max/QEMM.  Either of these programs will give you two things that the EMM
emulators won't: A VCPI interface and the ability to load programs into "high
DOS memory".

The Virtual Control Program Interface (VCPI) is a standard of behaviours and
capabilities that apply to programs that use the protected and virtual
8086 modes of operation in the '386. The VCPI allows you to map EMS/XMS
memory into the real mode address space and to have programs that use
extended memory (such as the various "DOS extenders") to coexist peacefully.
Multitaskers utilize the VCPI to control the mapping of virtual memory to
allow concurrent process operation. The VCPI provides virtual LIM 4.0
hardware as opposed to the emulated LIM 3.2 hardware you get from the EMM
emulators.

The ability of a program to load TSR's and device drivers into the 640K -
1Meg address space (known as "upper memory" or "High DOS memory") allows you
to keep some of your TSR's accessible without impacting on the lower 640K.
Unfortunately, this address space can become just as crowded as the lower
640K.  The VGA adapters usually take up the addresses from A000h (640K) to
C7FFh.  The ROM BIOS usually goes from F000h to FFFFh.  The EMS Page Frame
is usually mapped from E000h to EFFFh.  This means that you would usually
have the addresses between C800h and DFFFh free - a total of 96K.  If you
load the OMNIVIEW kernal into high memory it takes up another 48K from this
memory space - (the low DOS cost for OV would be 10-30K). Network adapters,
tape drives, some disk controllers and terminal emulation hardware can also
take up space in this area.

Two tricks - which should be applied with some caution - are to reclaim the
the portion of the segment at B000h that is used by the "other display's"
regen buffer: If you have a VGA and a color monitor you could use B000-B7FFh
for high DOS memory since that space is reserved for the mono text display.
Many machines with the "setup" program in ROM will put this program between
F000h and F7FFh - _as long as you don't run Setup_ you could map high DOS
memory into this space as well. Using both these tricks would gain you
another 64K of "high DOS".

│Also which multi-tasking program do you like if you
│were going out and getting one tommarow.  Hope you can help me out with
│this.  I'm running an Intel 386 at 25Mhz with 4Mb or ram and I like my
│TSR's allthough I've been doing without.

I like the combination of OMNIVIEW and 386Max - though, since I work for
Sunny Hill, you may want to evaluate that recommendation accordingly.

OMNIVIEW is a pre-emptive DOS multitasker.  It differs from DESQView
primarily in that all process are full screen (versus windowed)
applications.  OV is smaller and runs interrupt driven processes about
10-15% faster than DV. Unlike VM-386 there is a single copy of DOS - if you
need seperate COMFIG.SYS files, that is the probably the way to go - but it
takes about the same memory as OS/2 and is relatively slow.

"DESQView and TopView aware" programs will also be well behaved under OV.
Programs that specifically use the DESQView API will not work the same under
OV since the programmer's interface to the multitasking kernal is different.
The OMNIVIEW API is provided free of charge and supports Turbo Pascal, C and
Assembler programmers.

You can download an "expert system" (CONCUR00.ZIP) from Poverty Rock BBS in
Seattle - this program will give you an idea of how many process of what size
you can expect to get with OV.  This .ZIP also contains a text file
discussing the various kinds of memory available and how they are used by DOS
multitaskers.

Date: 01-09-90 (12:12)              Number: 255 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: continuous status display     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Howdy.  I've uploaded OVSTAT01.ZIP (16K) to Poverty Rock.

This file contains the Turbo C source and executable to a
continuous status display program. This program presents almost
the same information as does the standard OVSTAT program that
comes with OV except that it checks the state of the system and
updates the display about once every two seconds. This program
was written by Mike Toutonghi and was presented as part of an
OMNIVIEW series that appeared in Radio and Electronics last year.

Most of the program's work gets done inside a do() loop in
main(). After checking that OV is installed, the program gets the
process information on each of the ten possible processes using
tvgetoneinfo(). This information is displayed along with the free
memory and free swap space- obtained by a call to tvfreemem().
The program then calls ovdelay() which waits for two seconds or
until a key is pressed. The delay and keypress detection are both
accomplished with a single call that waits for something to show
up in the message queue. Testing the source of the message we get
tells us whether the delay expired before a key was pressed.
Pressing <Esc> will terminate the program.

Date: 01-20-90 (13:31)              Number: 265 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: BOB BLACHER'S CONFIG          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I thought this message I recently re-discovered might be of interest to
OV users considering multitasking on a network.

Date: 02-07-89 (00:16)        SYSOP Number: 664
  To: SYSOP
From: ROD RENNER                      Read: 02-07-89 (21:43)
Subj: 4 NODES NOW ON LINE HERE

Now that you've had experience in setting up LANtastic/Taskview
(Omniview) nodes, I have a not-so-hypothetical question for you:

Is it possible to set up a 6-node PCBoard system using just 3 machines
each running Omniview and connected with Lantastic?  If so, how would
you do it?  For that matter, if not, how would you do it?  I've been
approached by someone who is interested in setting up a 6-node system
and would appreciate suggestions from the experts on how that might best
be accomplished.

Date: 02-07-89 (21:43)        SYSOP Number: 665
  To: ROD RENNER                    Refer#: 664
From: SYSOP                           Read: NO
Subj: 4 NODES NOW ON LINE HERE

The answer is a qualified "yes", Rod.  You can run OmniView/TaskView on
top of LANtastic without any problems (including on top of machines that
are acting as servers).  But, to run 6 nodes on 3 machines you face at
least 2 problems: (1) Having enough memory to load the LAN software and
still have enough room for 2 partitions large enough to run PCBoard.
Because the machines here are '386s, I can use either 386^MAX or QEMM to
load the network software in high memory (above 640K) and increase
conventional DOS memory to 704-736K.  That leaves me plenty of room to
run 2 PCB nodes under OmniView/TaskView.  I think you'd have to give up
shells to DOS on a non-386.  (2) Performance is going to be marginal. At
2400 bps, I don't think you'll see any problems.  But, at 19.2K locked
in, pray your machine can handle the load of both the LAN and the
multi-tasker.  The only machine doing that here is a 20MHz 386.  I'd
sure as heck hate to see it done on a 4.77MHz PC <grin>.

If you assume that the 3 machines need to be high-performance 386's, I
wonder whether doubling up on those machines makes sense economically.
It might be cheaper (and undoubtedly more reliable) to buy 6 lowcost
machines.

Date: 01-21-90 (19:43)              Number: 271 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DAN THEIN                       Read: HAS REPLIES
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

What is OMNIVIEW?  This is a new conference to Smartnet and I am not
sure exactly what the product really is?

               Dan Thein
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 01-21-90 (18:25)              Number: 272 / 572 (Echo)
  To: DAN THEIN                     Refer#: 271
From: RICK KUNZ                       Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>What is OMNIVIEW?  This is a new conference to Smartnet and I am not
>sure exactly what the product really is?

 Greetings, Dan, and welcome. OMNIVIEW is a multitasker (formerly known
as TASKVIEW) which is a product of Sunny Hill Software in Seattle.
OMNIVIEW is known for its flexible interface and ability to operate in
network situations, and Sunny Hill Software is known for their fondness
for Sysops!

Dennis Edwards, of Sunny Hill Software, is the resident tech support
guru and the host of this conference. Pul#: 275
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

And we'll upload CONCUR00.ZIP to Sound Of Music BBS tonight, Dennis.
Thanks for the reminder!

Date: 01-23-90 (17:18)              Number: 277 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: VIC KASS                        Read: (N/A)
Subj: Whoops                        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


   In my previous message, the tagline incorrectly stated Rose Media's
   phone number as 416-731-2285. It should read: 416-733-2285.


           Regards .... Vic.
---
 ■ QNet 2.03: Rose Media | SmartNet Canadian Host |  416-733-2285
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 01-23-90 (19:05)              Number: 278 / 572
  To: DENNIS EDWARDS                Refer#: 275
From: FRANK MCADAMS                   Read: 03-16-90 (17:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

POVERTY ROCK, [phone]. One of these, named CONCURE00.ZIP is an "
                                                  123456789....
    Is this another feature of OmniView? (grin)
But seriously, it's good to see someone here who's an OmniView Techie,
Or are you? (hope you are anyways). Thanks for the info Dennis.

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Intelec (tm) Free Message Exchange

Date: 01-24-90 (07:12)              Number: 279 / 572 (Echo)
  To: FRANK MCADAMS                 Refer#: 278
From: RICK KUNZ                       Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>POVERTY ROCK, [phone]. One of these, named CONCURE00.ZIP is an "
>                                                  123456789....
>    Is this another feature of OmniView? (grin)

 CONCUR00.ZIP, Frank! <grin>. Maybe that's "CONCUR -- oh-oh!"

Date: 01-25-90 (01:24)              Number: 281 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 276
From: DENNIS EDWARDS                  Read: 01-25-90 (02:30)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│And we'll upload CONCUR00.ZIP to Sound Of Music BBS tonight, Dennis.

Thanks.

Date: 01-26-90 (07:08)              Number: 282 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DAVID CHRISTENSEN               Read: (N/A)
Subj: OmniView                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hi, Is this program commercial or shareware?  Just wondering..
---
 ■ DeLuxe 1.11ß20 #648  ■ From Bayport, Long Island, New York 11705-1304
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 02-01-90 (06:46)              Number: 283 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 282
From: DENNIS EDWARDS                  Read: NO
Subj: OmniView                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Hi, Is this program commercial or shareware?  Just wondering..

Commercial.
CONCUR00.ZIP is an expert system that will tell you what you can expect from
OV (or other multitasker) on your system. This .ZIP also includes a tutorial
on memory types and a description of OMNIVIEW.

The file is available on Poverty Rock ([phone]) and other fine BBSs.

Date: 02-02-90 (11:44)              Number: 284 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DAVID CHRISTENSEN               Read: 03-16-90 (17:36)
Subj: OmniView                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Date: 02-01-90 (06:46) (PVT)    Number: 77        Msg #17 out of 17

   FYI: Your message  is Private, dont know if  that was deliberate, but
   Priv mail does not go through the net relaibly.

DE>│Hi, Is this program commercial or shareware?  Just wondering..

DE>Commercial.
DE>CONCUR00.ZIP is an expert system that will tell you what you can expect from
DE>OV (or other multitasker) on your system. This .ZIP also includes a tutorial
DE>on memory types and a description of OMNIVIEW.

   Thanks for the info, will look for the file on Sound of Music.
---
 ■ DeLuxe 1.11ß20 #648  ■ This Message QMailed by The Liberator 2.2
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 02-02-90 (19:52)              Number: 285 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 284
From: RICK KUNZ                       Read: NO
Subj: OmniView                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  To: DENNIS EDWARDS

>   FYI: Your message  is Private, dont know if  that was deliberate, bu
>   Priv mail does not go through the net relaibly.

 David, the message Dennis sent was an open, public message at the
origin; it looks like there's something amiss in the configuration at
SOM. Your message was received r/o here also.

Date: 02-03-90 (20:06)              Number: 287 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: NONE
From: RICK KUNZ                       Read: NO
Subj: OmniView conference           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Date: 02-03-90 (13:34)     Omniview Number: 286 (Echo)
>  To: RICK KUNZ
>From: DAVID CHRISTENSEN               Read: YES
>Subj: OmniView                      Status: RECEIVER ONLY

>   Okey Dokey, Will let  Paul know. I had sent this as  a PUBLIC on SOM
>   made a point of sending the reply as public actually.

Yep, here's the reply you sent, and again it's r/o. I am pretty sure
Paul has been reconfiguring conferences today, so perhaps it's fixed
now. Thanks for following up.

Date: 02-04-90 (15:12)              Number: 288 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: DAVID CHRISTENSEN               Read: 02-04-90 (16:40)
Subj: OMNIVIEW CONFERENCE           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

   From: RICK KUNZ                          Status: Private, Read
Subject: OmniView conference            Conference: 87 OMNIVIEW

  As of  Sunday, R/O, this  has been happening  in the Disabled  conf as
  well?  Right? could  the Priv  only switch  be put  on in  PCBSETUP or
  PROSM?  Just a thought.


                                                    ...dC...
---
  ΣMail .38α This is REALLY it!
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 02-04-90 (16:41)              Number: 289 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 288
From: RICK KUNZ                       Read: NO
Subj: OMNIVIEW CONFERENCE           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  As of  Sunday, R/O, this  has been happening  in the Disabled  conf a
>  well?  Right? could  the Priv  only switch  be put  on in  PCBSETUP o
>  PROSM?  Just a thought.

 Yeah, it could be -- but it sure isn't here! I have checked about every
byte of 550 megs of storage, and it is either a weird bug in Rnet, or
some weird hex; other than that, all I can suspect is SOM.

Date: 02-23-90 (18:13)              Number: 290 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: ANOTHER LI'L UTIL             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Ran across WHATCHIP v 1.01 here on the board, and it could prove to be a
useful little util for determining a system's capability. Here's the
output from this system which has all the EMM used for cache/ramdisk.


WHATCHIP (tm) Memory Analysis Program   Version 1.01
Copyright 1989 Invisible Software, Inc.

Expanded Memory Manager:  Installed.
     Version number:  4.0.
     Total expanded memory:  1024K.
     Free expanded memory:  0K.
     AST enhanced functions:  Not available.

Chips and Technologies chipset:  NEAT version A.
     Total RAM on motherboard:  2048K.
     640K to 1M memory relocation:  Disabled.
     Shadow RAM:  Available.
     Expanded memory controller:  Enabled.
     EMS I/O port address:  0208
     EMS memory base address:  D400


Memory Map:

0000 - 9FFF    DOS  RAM
A000 - AFFF    VIDEO
B000 - B7FF
B800 - BFFF    VIDEO  RAM
C000 - C7FF    ROM
C800 - C9FF    ROM
CA00 - D3FF
D400 - DFFF    STANDARD-EMS  RAM
E000 - E3FF    STANDARD-EMS
E400 - EFFF
F000 - FFFF    BIOS  SHADOW  WRITE-PROTECTED

Date: 02-24-90 (02:40)              Number: 291 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: CODY GIBSON                     Read: (N/A)
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The Real Batchin' Board is pleased to join this conference.

PCRelay:BATCHIN -> SMARTNET + Pacific NW Region
4.10ß9             SmartNet-Node 2369-Real Batchin'[phone]

Date: 02-25-90 (20:50)              Number: 292 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: OV question                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, this appeared on the Saltair PCBoard support BBS, and I replied
that I'd post it for you here, and port a reply back if need be.

Date: 02-18-90 (19:11)              Number: 72024 / 72309
  To: ALL                           Refer#: NONE
From: VICTOR VOLKMAN                  Read: (N/A)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: SUPPORT (1)                Read Type: GENERAL

Does anybody have any hints for running a 2-node PCBoard 14.2/E3 system
with the OMNIVIEW multitasking system?  I am currently using OMNIVIEW
4.02 with two 295K partitions on a 25Mhz 80386 system running DOS 3.3.
I am using the /C:1 and /P:1 parameters which seem to give a fairly
smooth response.  However, it sometimes has trouble picking up the phone
and recycles once.  I have a HAYES 9600 v.42 (w/NS16550 UART) on node 1
and a generic 2400 EEPROM modem on node 2.

Thanks for any assistance!

HAL 9000 BBS, 313-663-4173, 2400/9600 HAYES v.42, Ann Arbor, MI

Oh yes, PCB=/DELAY:2/BIO

Date: 02-25-90 (11:50)              Number: 293 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DAVE CALMER                     Read: (N/A)
Subj: GENERAL STUFF...              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I've been watching this conference and from what I have seen so far
OMNIVIEW may be what I'm looking for. I have a 20mhz 386 with 4 meg of
ram. I would like to run 2 live nodes with a large enough window left
over for a "local" node or to run other programs in. Is this possible
under OMNIVIEW and if so how reliable is the setup (I'm not always
around to monitor the board) and what kind of performence can I expect.
If it makes any difference I can add another 12 meg of ram to the
motherboard if I need to...

-> MegaMail(tm) #398:
   1.00


PCRelay:DANGRZN -> Intelec (tm) North Central SuperRegional
4.10ß9             The Danger Zone! [phone] Rock Island,Il

Date: 02-28-90 (07:58)              Number: 294 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 290
From: DENNIS EDWARDS                  Read: 02-28-90 (10:57)
Subj: ANOTHER LI'L UTIL             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Ran across WHATCHIP v 1.01 here on the board, and it could prove to be a
│useful little util for determining a system's capability....
│
│WHATCHIP (tm) Memory Analysis Program Version 1.01
│Copyright 1989 Invisible Software, Inc.

Yes, that does have a couple nice features. I'm not sure how they talked to
the NEAT chip set - they probably followed the signature chain to locate the
ROMS. This last bit could be useful on 8088-'286 systems with real LIM 4.0
EMS. 386 memory managers usually have the capability to map ROMS built in.

Thanks for the post, Rick.
---
 ■ EZ 1.22 ■

Date: 02-28-90 (07:58)              Number: 295 / 572 (Echo)
  To: CODY GIBSON                   Refer#: 291
From: DENNIS EDWARDS                  Read: NO
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│The Real Batchin' Board is pleased to join this conference.

Good to hear from you, Cody.  Thanks for pickin' up the conference.
---
 ■ EZ 1.22 ■

Date: 02-28-90 (07:58)              Number: 296 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 292
From: DENNIS EDWARDS                  Read: 02-28-90 (10:57)
Subj: OV question                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis, this appeared on the Saltair PCBoard support BBS, and I replied
│that I'd post it for you here, and port a reply back if need be.

Thanks.

│Date: 02-18-90 (19:11)              Number: 72024 / 72309
│  To: ALL                           Refer#: NONE
│From: VICTOR VOLKMAN                  Read: (N/A)
│Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
│Conf: SUPPORT (1)                Read Type: GENERAL
│
│Does anybody have any hints for running a 2-node PCBoard 14.2/E3 system
│with the OMNIVIEW multitasking system?  I am currently using OMNIVIEW
│4.02 with two 295K partitions on a 25Mhz 80386 system running DOS 3.3.
│I am using the /C:1 and /P:1 parameters which seem to give a fairly
│smooth response.  However, it sometimes has trouble picking up the phone
│and recycles once.  I have a HAYES 9600 v.42 (w/NS16550 UART) on node 1
│and a generic 2400 EEPROM modem on node 2.
│
│Thanks for any assistance!
│Oh yes, PCB=/DELAY:2/BIO
│
│HAL 9000 BBS, 313-663-4173, 2400/9600 HAYES v.42, Ann Arbor, MI

I don't know what we'd be doing to make a modem not pick up. If my own
experience with ZOOM modems is any indication - it may be a problem with the
way the caller's modem trys to synch up which, of course, would happen
whether OV where running or not. At any rate he can get call in on
800-367-0651 and upgrade to vers 4.13. There have been some refinements to
the interrupt handlers that he might find useful on a '386.
---
 ■ EZ 1.22 ■

Date: 02-28-90 (10:58)              Number: 297 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 296
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: OV question                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>whether OV where running or not. At any rate he can get call in on
>800-367-0651 and upgrade to vers 4.13. There have been some refinements
>the interrupt handlers that he might find useful on a '386.


 I'll forward your response on, Dennis. What's the policy on upgrades?
I'm (finally) building a 386, and will be looking at OV and a decent
memory manager (QEMM?) when it's finished. Dunno what version I have.

Date: 02-28-90 (16:58)              Number: 298 / 572 (Echo)
  To: DAVE CALMER                   Refer#: 293
From: DENNIS EDWARDS                  Read: NO
Subj: GENERAL STUFF...              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I've been watching this conference and from what I have seen so far
│OMNIVIEW may be what I'm looking for. I have a 20mhz 386 with 4 meg of
│ram. I would like to run 2 live nodes with a large enough window left
│over for a "local" node or to run other programs in. Is this possible
│under OMNIVIEW and if so how reliable is the setup (I'm not always
│around to monitor the board)

You should have no problems. This is exactly the kind of thing OMNIVIEW was
designed to achieve quickly and reliably. By the time you get DOS, your
memory manager (we recommend 386MAX; Qualitas; Bethesda, MD) and OMNIVIEW
loaded up, you'll have about three Meg of RAM left over. The largest
individual partition size will, of course, depend on the amount of free space
you have left over now, minus 10-80K for OMNIVIEW. If you have a 48K
contiguous block of free memory between the video adapter and the BIOS ROMs
then you can load the OMNIVIEW kernal up there and lessen the impact it has
on your DOS TPA.  This last goes for some of the device drivers and TSRs you
may be running now as well.

EMS and XMS are global resources so each process you load, and each program
that uses these resources, will impact on the size and number of partitions
(up to a max of 10) that OMNIVIEW can load up. You can limit a programs
access to EMS. If you have a VGA system with 580K free, you would normally
get about 4 tasks of about 560K each with about a Meg of EMS left over. If
you have a Herc or MDA you can add another 64K to the max proc size, yet
another 32K for a CGA. Disk caches, RAM drives, etc. will effect these
numbers (as they impact on the global availability of EMS).

│and what kind of performence can I expect.

We figure about 100000 ints a second on a 20M 386. Another sysop reported
results of his own comparison between OMNIVIEW and DV here awhile back, and
found about 10-20% better throughput with OMNIVIEW.

│If it makes any difference I can add another 12 meg of ram to the
│motherboard if I need to...

Depends on how many additional procs, caches, ram drives, etc. you need. Also
depends on the use of your non-BBS program's use of EMS. If you load device
drivers or TSRs up into high memory this will also impact on EMS - loading
them low will impact on the DOS TPA. Less is seldom more when it comes to
memory, though.
---
 ■ EZ 1.22 ■

Date: 02-28-90 (16:59)              Number: 299 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: external interface to OV      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have uploaded a file to Poverty Rock (206-232-1763) called OVXIFC0.ZIP.

This 6.5K archive contains two text files, one being simply a description of
OMNIVIEW. The archive's file of interest to programmers describes an
interface to OMNIVIEW that is accessible to resident programs installed
before the multitasker. The interface generates a series of "signals" that
inform "external" programs of process events: Events such as task creation,
context switches and foreground task changes.

By utilizing this interface you could build programs that fed keystrokes to
background processes, for instance. Another use would be to verify access to
a global memory area set aside in upper memory for OMNIVIEW processes. Still
another use would be to allow a "swappable TSR" to recognise when a
multitasker was loaded on top of it.

The interface has been used consistently in utility programs bundled with
OMNIVIEW. Each signal is generated using software interrupt 15h with the
function numbers passed in AX. This document describes the purpose and
conventions of these signals and discusses implementation considerations for
programs utilizing the interface along with OMNIVIEW Application Programmer's
Interface (OAPI).
---
 ■ EZ 1.22 ■

Date: 02-28-90 (17:27)              Number: 300 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 299
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: EXTERNAL INTERFACE TO OV      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I have uploaded a file to Poverty Rock (206-232-1763) called
>OVXIFC0.ZIP. This 6.5K archive contains two text files, one being
>simply a description of OMNIVIEW.  The archive's file of interest to
>programmers describes an interface to OMNIVIEW that is accessible to
>resident programs installed before the multitasker.

Thanks for the upload and description, Dennis. I'll make sure the file
gets to our various "HQ" boards as well as make it requestable
through the PCRelay software, or downloadable first call from Poverty
Rock.

Date: 03-01-90 (06:45)              Number: 302 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 297
From: DENNIS EDWARDS                  Read: 03-01-90 (06:47)
Subj: OV question                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>whether OV where running or not. At any rate he can get call in on
│>800-367-0651 and upgrade to vers 4.13. There have been some refinements
│>the interrupt handlers that he might find useful on a '386.
│
│ I'll forward your response on, Dennis. What's the policy on upgrades?

Thanks, Rick. Right now, they are free.

│I'm (finally) building a 386, and will be looking at OV and a decent
│memory manager (QEMM?) when it's finished. Dunno what version I have.

Congrats on the new box. You need to go with 386MAX right now for the memory
manager. QEMM doesn't allow us to do interrupts in EMS.
---
 ■ EZ 1.22 ■

Date: 02-25-90 (23:22)              Number: 303 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: CODY GIBSON                     Read: 03-16-90 (17:36)
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> Good to hear from you, Cody.  Thanks for pickin' up the conference.

And thanx for the welcome. Can you tell me if Omniview is compatible w/
NetBios Lan drivers? I've tried DESQview and found it locks up my server
every time a workstation attempts to access it. Only thing I can do to
clear it is a total power down and system wide reset. I really do need
multi-tasking capabilities on my 386 server. DESQview would do the job if
it wouldn't lock up on me.

PCRelay:BATCHIN -> SMARTNET + Pacific NW Region
4.10ß9             SmartNet-Node 2369-Real Batchin'[phone]

Date: 03-01-90 (21:33)              Number: 304 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DAVID CHRISTENSEN               Read: HAS REPLIES
Subj: Hello?                        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hi, anyone  out there? I keep  seeing messages comming in  & my pointers
keep going up, but get no messages  in my packet for this conference. Oh
well...L8r!
===
  ΣMail 0227α Watch out world, I'm driving!!
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-01-90 (22:36)              Number: 305 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 304
From: RICK KUNZ                       Read: NO
Subj: Hello?                        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Hi, anyone  out there? I keep  seeing messages comming in  & my pointer
>keep going up, but get no messages  in my packet for this conference. O
>well...L8r!

 Sheesh, I thought this was fixed at SOM... your message was received
as an r/o message here at Poverty Rock, David. I'll post a note to Paul
Waldinger on the problem.

Date: 03-01-90 (22:54)              Number: 306 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 298
From: DAVE CALMER                     Read: 03-16-90 (17:36)
Subj: GENERAL STUFF...              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>You should have no problems. This is exactly the kind of thing OMNIVIEW
>designed to achieve quickly and reliably. By the time you get DOS, your

Sounds like just the thing I'm looking for. I have used Desqview in the
past and always had a hard time getting it to run reliably for extended
periods (the system crashed every 12 hours or so) I know the problem was
something I caused but...

Now for the BIG question...how much does this little gem cost and where
can I order it? Thanks for the quick response on this, you did a great
job answering my questions except...

>We figure about 100000 ints a second on a 20M 386. Another sysop report

can you break this down to a cps rate? Currently on the 12 mhz 286 with
com port open at 19200 my callers get around 1650 cps (give or take a
hundred), this is no major concern by any means but since most of the
high speed callers bought their modems from me they EXPECT it to be fast
so I'd like to plan my excuses early!

>access to EMS. If you have a VGA system with 580K free, you would norma
>get about 4 tasks of about 560K each with about a Meg of EMS left over.

okay that sounds real good, I do run VGA (hey it's not ALL work around
here!) and most anything I'd need to run would work well in a window
that size, what about running a "game" while the board is up (aside from
memory) how well does the video part work? I have quite a few programs
that won't run in MS WINDOWS (I know it's a different animal) in VGA
because of the video type (or so it says)...

Like I said these are minor points to me but I thought I'd check first,
please try and leave me some price and ordering info, you have me sold!
---
 * Via ProEdit 3.1

Date: 03-03-90 (08:09)              Number: 308 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 300
From: DENNIS EDWARDS                  Read: 03-03-90 (09:12)
Subj: EXTERNAL INTERFACE TO OV      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>I have uploaded a file to Poverty Rock (206-232-1763) called
│Thanks for the upload and description, Dennis. I'll make sure the file
│gets to our various "HQ" boards as well as make it requestable
│through the PCRelay software, or downloadable first call from Poverty
│Rock.

Thanks, Rick.

Is there a consolidated node list describing this file accessibility?
---
 ■ EZ 1.22 ■

Date: 03-03-90 (08:09)              Number: 309 / 572 (Echo)
  To: CODY GIBSON                   Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Can you tell me if Omniview is compatible w/
│NetBios Lan drivers? I've tried DESQview and found it locks up my server
│every time a workstation attempts to access it. Only thing I can do to
│clear it is a total power down and system wide reset. I really do need
│multi-tasking capabilities on my 386 server.

There are some of the smaller networks, most notably Lantastic, where we will
run on the server or the remotes. It always takes a little more room for the
partitions, and you can't run "the shell" out of the page frame, but other
than that it's nothing unusual (at least on Lantastic). As a general rule,
though, it really isn't designed to run off the server - especially with the
the bigger networks like Novel, 3Com, etc. In these latter cases the
suggestion is "start it from a local drive on the remote".
---
 ■ EZ 1.22 ■

Date: 03-03-90 (09:14)              Number: 310 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 308
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: NODELISTS                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Is there a consolidated node list describing this file accessibility?

 For Smartnet, the nodelist is in progress and right now there isn't an
up-to-the-minute compilation. On INTELEC, the nodelist is available here
on Poverty Rock as INNL0224.ZIP

Date: 03-03-90 (12:55)              Number: 311 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: CODY GIBSON                     Read: 03-16-90 (17:36)
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> the bigger networks like Novel, 3Com, etc. In these latter cases the
> suggestion is "start it from a local drive on the remote".

Thanx for the info. I'm running a 2 node system using "Network-OS" by
CBIS. So it's not Lantastic, but an equivalent. Next question: Where do I
get Omniview and how much?

PCRelay:BATCHIN -> SMARTNET + Pacific NW Region
4.10ß9             SmartNet-Node 2369-Real Batchin'[phone]

Date: 03-04-90 (21:30)              Number: 312 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: NONE
From: PAUL WALDINGER                  Read: NO
Subj: Hello?                        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

David,
       This conference is very much alive.  It seems that one of the
nodes which is using a conversion program to import directly into
PCBoard is having problems with the conversion.  I have continually
checked the configuration on this system, in this and other conferences
where the problem seems to be recurring, and only with one system as
well.

                ......Paul Waldinger-Sysop....
               ...Smartnet International Host....

---
 ■ Via ProEdit 3.2ßR
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-05-90 (08:20)              Number: 313 / 572 (Echo)
  To: DAVE CALMER                   Refer#: 306
From: DENNIS EDWARDS                  Read: 03-12-90 (18:50)
Subj: GENERAL STUFF...              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>You should have no problems. This is exactly the kind of thing OMNIVIEW
│>designed to achieve quickly and reliably. By the time you get DOS, your
│Sounds like just the thing I'm looking for. I have used Desqview in the
│past and always had a hard time getting it to run reliably for extended
│periods (the system crashed every 12 hours or so) I know the problem was
│something I caused but...
│Now for the BIG question...how much does this little gem cost and where
│can I order it?

The cost is $79.95 and sysops get a 35% discount.  You will also need 386^Max
which you can order through us.

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

[phone]


│ Thanks for the quick response on this, you did a great
│job answering my questions except...

│>We figure about 100000 ints a second on a 20M 386. Another sysop report
│can you break this down to a cps rate? Currently on the 12 mhz 286 with
│com port open at 19200 my callers get around 1650 cps (give or take a
│hundred), this is no major concern by any means but since most of the
│high speed callers bought their modems from me they EXPECT it to be fast
│so I'd like to plan my excuses early!

It seems to me he counted around 1800-2000 cps. (Max rate at 19200bps would
be 2400cps).

│>access to EMS. If you have a VGA system with 580K free, you would norma
│>get about 4 tasks of about 560K each with about a Meg of EMS left over.
│
│okay that sounds real good, I do run VGA (hey it's not ALL work around
│here!) and most anything I'd need to run would work well in a window
│that size, what about running a "game" while the board is up (aside from
│memory) how well does the video part work? I have quite a few programs
│that won't run in MS WINDOWS (I know it's a different animal) in VGA
│because of the video type (or so it says)...

As long as a program is visible (running one of the two possible displays),
it will run in any graphics mode supported by the display system. We save and
restore all standard BIOS video modes. A program that runs in EGA or VGA
graphics will be turned off when it is in the background. Text and CGA
graphics run in the background.
---
 ■ EZ 1.22 ■

Date: 03-06-90 (20:07)              Number: 314 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 310
From: DENNIS EDWARDS                  Read: 03-06-90 (21:29)
Subj: NODELISTS                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>Is there a consolidated node list describing this file accessibility?
│ For Smartnet, the nodelist is in progress and right now there isn't an
│up-to-the-minute compilation. On INTELEC, the nodelist is available here
│on Poverty Rock as INNL0224.ZIP

And all the INTELEC/Smartnet boards have file echo capability?
---
 ■ EZ 1.22 ■

Date: 03-06-90 (20:07)              Number: 315 / 572 (Echo)
  To: CODY GIBSON                   Refer#: 311
From: DENNIS EDWARDS                  Read: NO
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│> the bigger networks like Novel, 3Com, etc. In these latter cases the
│> suggestion is "start it from a local drive on the remote".
│
│Thanx for the info. I'm running a 2 node system using "Network-OS" by
│CBIS. So it's not Lantastic, but an equivalent. Next question: Where do I
│get Omniview and how much?

OMNIVIEW lists at $79.95 but sysops get a 35% discount.

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

800-367-0651
---
 ■ EZ 1.22 ■

Date: 03-06-90 (21:29)              Number: 316 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 314
From: RICK KUNZ                       Read: 03-16-90 (17:36)
Subj: NODELISTS                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>And all the INTELEC/Smartnet boards have file echo capability?

 Nope; only the PCRelay boards on INTELEC have the ability to request
files directly, Dennis. Any of the boards which call here as their hub
using PCRelay could request things, so it's probably best to just upload
the appropriate files to key locations on the networks.

Date: 03-06-90 (23:06)              Number: 317 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 313
From: DAVE CALMER                     Read: 03-16-90 (17:36)
Subj: GENERAL STUFF...              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks for the all the great input, nice to know what I'm getting into
here...well the computer is due in next week and the phone lines the
first week of April...thanks for making the choice "painless" for me.

-> MegaMail(tm) #398:Don't confuse me with facts, my mind's made up!!
   1.00


PCRelay:DANGRZN -> Intelec (tm) North Central SuperRegional
4.10ß9             The Danger Zone! [phone] Rock Island,Il

Date: 03-07-90 (22:34)              Number: 318 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 316
From: CODY GIBSON                     Read: 03-16-90 (17:36)
Subj: Joining                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> Seattle, WA 98155-5278
>
> 800-367-0651

Thanx for the number. Since I am in Bellevue, is there a local Seattle
number I can call rather than the 1-800 number? I know that some 1-800
numbers don't work within state boundarys (and would be cheaper for you
too).

PCRelay:BATCHIN -> INTELEC-NET * NorthWestern Region
4.10ß9             Real Batchin', Issaquah, Wa. 206-391-2330 HST

Date: 03-08-90 (23:41)              Number: 319 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 316
From: DENNIS EDWARDS                  Read: 03-09-90 (04:13)
Subj: NODELISTS                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>And all the INTELEC/Smartnet boards have file echo capability?
│ Nope; only the PCRelay boards on INTELEC have the ability...

OK. Thanks.

│it's probably best to just upload the appropriate files to key locations on
│the networks.

<hint>...
---
 ■ EZ 1.22 ■

Date: 03-09-90 (12:38)              Number: 320 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: TIM FARLEY                      Read: HAS REPLIES
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have finished setting up the second node of our BBS (Semware QEdit
support BBS, 404-641-8968) under Omniview, and it seems to run OK.

We're running on a 10 Mhz 286 machine, with 640K on the motherboard and
512K of extra RAM on a RAMpage Plus/286 card, that gives us EMS 4.0
hardware compatibility.  I have a monochrome card in the system, and of
course the 640K area gets backfilled to 704K by OmniHigh when I load it.

So I can load two 296K partitions, each with PCBoard 14.2/E3 running in
them.  We have USR HST 1440 modems on each.

I have only installed a 16550AN UART on one partition so far, and that
partition seems to lock up every three hours or so.  A caller will hang
up, and then it will totally ignore the modem.  RTS gets stuck high.  If
I reset the machine, it will recover usually, a power down definitely
recovers.

Is there something special I need to do with 16550's under OV?

--Tim Farley
  SemWare

Date: 03-09-90 (18:06)              Number: 321 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 320
From: RICK KUNZ                       Read: 03-10-90 (13:44)
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I have only installed a 16550AN UART on one partition so far, and that
>partition seems to lock up every three hours or so.  A caller will hang
>up, and then it will totally ignore the modem.  RTS gets stuck high.  I
>I reset the machine, it will recover usually, a power down definitely
>recovers.
>
>Is there something special I need to do with 16550's under OV?

 Greetings, Tim! Nice to have you drop by and even nicer to hear that
the SemWare BBS is going multinode with Omniview!

 One question on the ports: Do you by chance have a two-UART serial card
and is the 16550 installed on port 2? Reason I ask is that I have had
half a dozen or so cheap clone serial cards with socketed UARTS, and on
at least two of them, for some weird reason, the 16550 just would not
operate on the first port, but would operate fine on the second port.

 If you feel like swapping the UARTS and can do it with the port config
you have, try sticking the 16550 on COM2 and see if you get the same
problem; if not, then you have a card like those I mentioned. I tried
these on several different machines just to see if it was my other
hardware, and they would lock up on COM1 and purr right along on COM2.
Strange!

 Anyway, good luck with the configuration and thanks for dropping by. We
hope you'll take the Omniview support conference when you get the
SemWare BBS linked up with our networks!

Date: 03-10-90 (13:43)              Number: 322 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 321
From: TIM FARLEY                      Read: 03-10-90 (15:03)
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Yes, as a matter of fact, the serial ports ARE on a clone dual-port
serial board, and the one that is messing up is the second one, I think.

I'll have to check that, meanwhile, let me tell you what kind of card it
is, in case it is already on your list of "cards that don't like
16550's".....

It is an "IOSA CARD" version 3.0, it came with one of our PCBrand 386
systems.  It has two sockets for 8250/16450/16550 chips (oriented
vertically) and one hard-wired LPT port.  It has a row of jumpers across
the top edge of the card, eight for each COM port, and six for the LPT
port selection.  You move pairs of jumpers to select the ports.  Kind of
like this:

 L3  L2  L1  C4  C3  C2  C1  C4  C3  C2  C1
┌───────────────────────────────────────────┐
│o o o o o o o o o o o o o o o o o o o o o o│
│                    │ │         │ │        │
│o o o o o o o o o o o o o o o o o o o o o o│
└───────────────────────────────────────────┘

I think I have them jumpered as indicated, where one port is on
COM3 (to keep it out of the way of the motherboard COM1 which I'm
not sure I can disable--a whole other problem) and the one in
question is on COM2.

I will try swapping to a different card.

Thanks for the tip.

--Tim Farley

Date: 03-10-90 (18:32)              Number: 323 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 315
From: MIKE STROCK                     Read: 03-16-90 (17:36)
Subj: OmniView/PCBoard              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I am currently setting up a bbs for my employer, using PCBoard.  It
is currently running on an XT.  We have ordered (in the process  of
ordering,  I  should say),  the E3 version of PCBoard 14.2 (the 1-3
node version).  I am wondering if I can run two nodes of PCBoard on
a 640k XT with Omniview?  How about on an AT (when I move up to  an
AT at some point)?  Thanks,
  Mike Strock
---
 ■ EZ 1.26 ■

Date: 03-10-90 (21:31)              Number: 324 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 322
From: RICK KUNZ                       Read: 03-12-90 (08:24)
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I'll have to check that, meanwhile, let me tell you what kind of card i
>is, in case it is already on your list of "cards that don't like
>16550's".....
>
>It is an "IOSA CARD" version 3.0, it came with one of our PCBrand 386
>systems.  It has two sockets for 8250/16450/16550 chips (oriented
>vertically) and one hard-wired LPT port.  It has a row of jumpers acros
>the top edge of the card, eight for each COM port, and six for the LPT
>port selection.  You move pairs of jumpers to select the ports.

 Tim, the card you have is a bit more sophisticated than the cheap clone
serial cards I've had problems with, but it could well be some sort of
conflict with the serial port on the momboard of your machine. My old
Leading Edge XT had a jumper to disable the onboard serial port so
perhaps yours does too, and that might do the trick. Let us know if
changing the port works -- good luck!

Date: 03-10-90 (21:33)              Number: 325 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 323
From: RICK KUNZ                       Read: 03-11-90 (07:39)
Subj: OmniView/PCBoard              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I am currently setting up a bbs for my employer, using PCBoard.  It
>is currently running on an XT.  We have ordered (in the process  of
>ordering,  I  should say),  the E3 version of PCBoard 14.2 (the 1-3
>node version).  I am wondering if I can run two nodes of PCBoard on
>a 640k XT with Omniview?  How about on an AT (when I move up to  an
>AT at some point)?  Thanks,

Hi, Mike -- I don't presume to be even close to being considered
knowledgeable about Omniview, but Dennis usually doesn't call in on
weekends, so I'll give an unsolicited opinion: I think it'll be tough to
run two nodes on one XT under OV, but it might be done. You will
probably not have room for external protocols from the main board; those
can, of course be handled by a third-party program such as Zdoor or
ProDoor. You will be at the bare minimum for each node, and you
shouldn't have a whole lot of DOS overhead -- perhaps mono monitor,
etc. I don't know what the minimum memory for PCBoard is suggested to
be, but it seems to me I had to allocate about 240k per partition when
fiddling with the "least possible". You could probably optimize that a
bit by making sure all buffers are small (upload buffer, screen buffer,
etc), but really, it runs much better on an AT with memory-configurable
hardware.

You can have a pretty good workspace for maintenance, etc, in a smaller
bottom partition, perhaps 180-200k, and still have room for a decent
main node if you don't want to take the second node "live" on an XT.

If it does run two nodes, it will be pretty slow in operation on an XT.

Perhaps one of the PCBoard gurus already running under OV can be more
enlightening; good luck, and keep us posted!

Date: 03-12-90 (08:34)              Number: 326 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: TIM FARLEY                      Read: 03-12-90 (18:03)
Subj: SERIAL PROBLEMS               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have since tried using the other UART socket on the card, and it still
locked up on me once.  This time, it happened while *I* was online
remotely, so I got a good idea of what happens---apparently the incoming
flow control gets "stuck" so that the BBS no longer sees input from the
modem.

I was still getting output on my screen from Prodoor, but it would
ignore all input from me---I would see the lights on the BBS's modem
flash, but no input.  Prodoor was alive and well--I could go type on the
console, and it would hum merrily along, and output would go over the
modem.  Just no remote input.  Oddly enough the RS light was ON, on the
BBS's modem through all this, though it was actually acting like RTS was
stuck *down*.

I tried one last thing on Saturday, which was a stab in the dark based
on something in the DSZ docs:  I put STACKS=8,256 in the CONFIG.SYS and
rebooted the BBS.

Amazingly enough, the system has run solidly from Saturday evening till
Monday morning, so it seems to be resolved now.  I'm not convinced that
I have "really" found the problem, though---because it was so
intermittent, it's hard to say its really gone now.

Thanks for the help.

--Tim

Date: 03-12-90 (18:06)              Number: 327 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 326
From: RICK KUNZ                       Read: 03-12-90 (18:49)
Subj: SERIAL PROBLEMS               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I tried one last thing on Saturday, which was a stab in the dark based
>on something in the DSZ docs:  I put STACKS=8,256 in the CONFIG.SYS and
>rebooted the BBS.

 You read Forsberg's DOCS? <grin>. Indeed, who knows; if that fixes it
-- and I'll be real interested in knowing for sure when you've had a
longer run at it -- it'll be great!

 The card could be one of those that was never designed for proper flow
control; I don't claim to be the guru on this stuff, but when I have
something work like that, then I touch the computer ever so gingerly for
a while until I'm sure, too. <grin>

Date: 03-12-90 (18:54)              Number: 328 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 313
From: TIM FARLEY                      Read: 03-16-90 (17:36)
Subj: USE OF "NUL                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I am curious if there is some unusual handling of the NUL device while
Omniview is running.

I have noticed that certain redirections of NUL no longer work as
expected while inside OV.  For instance, a shortcut I often use to
remove the "comment" filed from a .ZIP file, is the following:

     PKZIP -Z WHATEVER.ZIP <NUL

PKZip detects the redirection, and instead of waiting for input, it zaps
the comment field in that ZIPfile to nothing.

But not in Omniview.  The above statement will cause an infinite wait at
the Zip comment? prompt.

I have also noticed that the PKUNZIP -T option takes FAR, FAR longer
inside Omniview than it does outside.  Far slower than could be
explained by multitasking alone.  According to the DOCs, when PKUNZIP
"tests" a ZIPfile (that's what -T is for) it actually UNZIPs the
component files to the NUL device.  Perhaps this is a related problem?

Any light you could shed on this would be much appreciated.

--Tim Farley
  SemWare

Date: 03-12-90 (19:35)              Number: 329 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 328
From: RICK KUNZ                       Read: 05-01-90 (14:45)
Subj: USE OF "NUL                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>     PKZIP -Z WHATEVER.ZIP <NUL
>
>PKZip detects the redirection, and instead of waiting for input, it zap
>the comment field in that ZIPfile to nothing.
>But not in Omniview.  The above statement will cause an infinite wait a
>the Zip comment? prompt.

 Hmm, I didn't have that problem when I loaded OV and tried it, Tim.
Tried both a top window of 300k+ and a smaller, 200k one and it worked
just fine. I know this is probably a stupid question for a person of
your expertise, but are you _sure_ pkzip has plenty of memory in the
window you're trying this in?

>I have also noticed that the PKUNZIP -T option takes FAR, FAR longer
>inside Omniview than it does outside.  Far slower than could be
>explained by multitasking alone.  According to the DOCs, when PKUNZIP
>"tests" a ZIPfile (that's what -T is for) it actually UNZIPs the
>component files to the NUL device.  Perhaps this is a related problem?

 Now that I did find to be the case under OV. I am not running OV
regularly right now (waiting until I get the chance to really
configure my 386 momboard) but I tried testing a few ZIPs and it was
indeed quite a bit slower, even on a RAMdisk it was noticeable. I wonder
if this can be "tuned" with temporary workspace if you have some free
EMS memory.

Date: 03-14-90 (02:50)              Number: 330 / 572 (Echo)
  To: DAVIDSON CORRY                Refer#: NONE
From: DENNIS EDWARDS                  Read: NO
Subj: use 800 tele num              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Sorry I didn't get back here sooner. Go ahead and use the 800 number. It
works for anyone in the US and the order stuff is set up around it.
---
 ■ EZ 1.22 ■

Date: 03-14-90 (02:50)              Number: 331 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 323
From: DENNIS EDWARDS                  Read: NO
Subj: OmniView/PCBoard              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I am currently setting up a bbs for my employer, using PCBoard.  It
│is currently running on an XT.  We have ordered (in the process  of
│ordering,  I  should say),  the E3 version of PCBoard 14.2 (the 1-3
│node version).  I am wondering if I can run two nodes of PCBoard on
│a 640k XT with Omniview?  How about on an AT (when I move up to  an
│AT at some point)?  Thanks,
│  Mike Strock

Let me answer the last question first. The "only" thing you'll get by
upgrading to an AT, as far as OV goes, is a faster system. Memory constraints
will be the same for any system based on anything less than a 386. With a 386
running 386MAX you can have up to ten partitions as large as the remaining
RAM in the DOS TPA (assuming you had sufficient EMS). Any of these processes
could be handling background communications so long it had a unique IRQ and
COM port.

On a 286 or less you must make the processes non-swappable in order for them
to reliably service interrupts. This means that each of your two COM programs
must be able to fit in memory (along with OV, DOS and any TSR's or device
drivers) at the same time. Without LIM 4.0 EMS and assuming that you had 580K
free after your AUTOEXEC runs - and figuring 60K for OV - you should end up
with two procs of about 260K each. This may not be enough for you to run the
doors you want. You can use Turbo Power's EATMEM or some other TSR
combinations to reduce your available RAM to that level and then find out if
PCBOARD does what you want.

If you were to install a LIM 4.0 EMS board in either an XT or AT you
then you could use it in two ways to increase the size of the DOS TPA - the
Area of RAM available for running Transient Programs. First you could load
the OV kernal into "upper memory" - the space between the top of the video
adapter and the bottom of the BIOS ROMs. This trick requires a 48k contiguous
EMS block to be allocated. Depending on your EMM driver, you may have to add
a command line switch to allow this allocation to take place.

To take advantage of the second trick you must have a monochrome (MDA or
Herc) or CGA video adapter (or a combination of them but no EGA or VGA) in
the BBS system. OV will then "backfill" the area between 640K and and the
bottom of the regen buffer with EMS to increase the size of the TPA. If a
monochrome card is in the system you gain 64K and if a CGA is the only
adapter then you get an extra 96K. Since this memory can be used to run
programs you could have about 280K per proc.
---
 ■ EZ 1.22 ■

Date: 03-14-90 (02:50)              Number: 332 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 320
From: DENNIS EDWARDS                  Read: 05-01-90 (14:45)
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I have only installed a 16550AN UART on one partition so far, and that
│partition seems to lock up every three hours or so.  A caller will hang
│up, and then it will totally ignore the modem.  RTS gets stuck high.  If
│I reset the machine, it will recover usually, a power down definitely
│recovers.
│
│Is there something special I need to do with 16550's under OV?

Howdy.
This is an odd problem. There is nothing special you need to do for different
kinds of UARTS under OMNIVIEW.

If the problem shows up again, you should be able to determine if OMNIVIEW
has dropped the ball by looking to see if the IRQ for the troubled port is
still enabled - in the interrupt mask registers for both the UART and the
PIC. If they are still enabled then I would have to think that the problem
lies some where within the hardware for the port - perhaps in the line
drivers? I can give you a debug script to check this if you aren't familiar
with the hardware.

Since it appears that you have input to both partitions at once, I think OV
is doing what it is supposed to. You seem to have met the basic requirement
that there are different IRQ's for each port and that they are assigned
different addresses. Not having that, of course, would result in strange
behavior from the system.

Since the troubled partition accepts console input, it does not seem that
you have a memory shortage. Have you tried just killing the "dead" node and
bringing it back up? You would have to get to DOS in the other node and run
SPAWN or OPEN to restart it.

I noticed that you have talked to Rick about this problem and I am also
unsure that changing the STACKS setting would solve this. Usually the effects
of a stack problem are more spectacular. They usually are intermittent and
related to interrupts though, so who knows.

Please let me know how this goes.
---
 ■ EZ 1.22 ■

Date: 03-17-90 (16:06)              Number: 333 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 331
From: MIKE STROCK                     Read: 03-19-90 (14:07)
Subj: OmniView/PCBoard              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thank you Dennis for the reply.  I will be looking into this more
in the future, but I thank you for the quick reply.

Mike.
---
 ■ EZ 1.26 ■

Date: 03-19-90 (14:07)              Number: 334 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 316
From: DENNIS EDWARDS                  Read: 03-19-90 (14:09)
Subj: NODELISTS                     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Not nodelists, exactly, but...

I was able to find the data from the lost OMNIDOS0.ZIP among the old
messages for this conference.  I will re-do the ZIP and send it up to you
next week - assuming my jury duty doesn't get me locked away.
---
 ■ EZ 1.22 ■

Date: 03-19-90 (14:07)              Number: 335 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 328
From: DENNIS EDWARDS                  Read: 05-01-90 (14:45)
Subj: USE OF "NUL                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I have noticed that certain redirections of NUL no longer work as
│expected while inside OV.  For instance, a shortcut I often use to
│remove the "comment" filed from a .ZIP file, is the following:
│
│     PKZIP -Z WHATEVER.ZIP <NUL
│
│PKZip detects the redirection, and instead of waiting for input, it zaps
│the comment field in that ZIPfile to nothing.
│But not in Omniview.  The above statement will cause an infinite wait at
│the Zip comment? prompt.

Howdy. I was going through the message base looking for some old posts - and
discovered that my previous reply to you is not there. I apologise...

Unfortunately, I was not able to duplicate this on my systems here. Each runs
DOS 3.3.

│I have also noticed that the PKUNZIP -T option takes FAR, FAR longer
│inside Omniview than it does outside.  Far slower than could be
│explained by multitasking alone.  According to the DOCs, when PKUNZIP
│"tests" a ZIPfile (that's what -T is for) it actually UNZIPs the
│component files to the NUL device.  Perhaps this is a related problem?
│
│Any light you could shed on this would be much appreciated.

This I was able to see for myself. And, at first, it was a puzzle. The key to
this behavior is that NUL is a device. We filter all int 21h function 40h
calls - which is what he uses to do the UNZIP. If the call is to a
non-redirected device, we then break it up so that all other tasks in the
system aren't waiting for a daisy wheel to get done printing a user's manual
before they get a chance to run.

What we will do is add a check to non-redirected devices to see if that
device is NUL and, if so, treat it just like a file. This should give the
desired results to everyone.

Thanks for bringing this to our attention - I never did an archive test
outside OV before so I didn't realize the performance disparity.
I did notice the message below (which Rick copied into the OMNIVIEW
conference a while back). It may help you with the .ZIP testing until we get
the NUL test implemented. Perhaps using a RAM disk and ATTRIB could simplify
this process.

>Date: 06-26-89 (17:02)     TOOLSUPP Number: 3275
>  To: BILL WALSH
>From: SAMUEL SMITH                    Read: NO
>Subj: AN OLD PROBLEM REVISITED
>
>BW>Sam, I seem to recall a problem with ProDoor and Omniview (Taskview)
>BW>testing uploads during the ARC days.  I have recently experienced sy
>BW>hangs and abnormal terminations at the point that ProDoor tests uplo
>BW>.ZIP files.  Do you recall what the workaround for that problem was?
>
>Yes, the work around was to go to a non-Katz ARC tester.  It seems that
>Katz continues to use the routines that are incompatible with Omniview.
>As a kluge-around you might change the PKUNZIP -T to actually unzip the
>files into a scratch directory, then delete them afterwards.  Only
>problem is that you will start collecting all the hidden members in
>tested uploads.
>
> ;; Sam
---
 ■ EZ 1.22 ■

Date: 03-19-90 (14:07)              Number: 336 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: ov support files              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Some time ago, I presented a tutorial on using the OMNIVIEW
command line interface to create various DOS partitions.
Unfortunately, (especially for Rick) this file was lost when
Poverty Rock BBS experienced a hard disk crash.
The text from these messages and the various batch files have
been uploaded to Poverty Rock (206-232-1763) as:

OMNIDOS0.ZIP
    Some features of this 10K batch file collection/tutorial
    include setting a partition's environment size from an
    environment variable, running various programs using a
    standard batch file, determining the reason OMNIVIEW has
    "dismounted from memory" and setting the prompt to
    indicate the Console Number of the current partition.

I am also uploading a NEW file called:

DETECT00.ZIP
    This 10K file describes how to detect the presence of a
    DOS multitasker such as OMNIVIEW and discusses how to
    make your programs "multitasker aware". These techniques
    rely on the BIOS interrupt 10h extensions introduced by
    IBM with TopView (IBM's DOS multitasking product) and
    also work with DESQview. This file includes example .ASM
    and .C functions for reading the keyboard and writing
    directly to a virtual or physical screen.

Poverty Rock also offers other files of interest to OMNIVIEW
users. If your local BBS is a PCRelay board on INTELLEC, you
should also be able to get these files via "the hub". Here is a
summary of the other support files:

OVAPPN00.ZIP
    A lot of common problems are discussed in this 32K
    collection of OMNIVIEW application notes including moving
    from the menu interface to the command line, high speed
    communications, various memory types, interrupt handling,
    sheduling, TopView emulation, and process visibility.

CONCUR00.ZIP
    This program (40K) is an "expert system" that can be
    useful in evaluating a system's capability for use with a
    DOS multitasker. The program offers specific information
    about the number and size of OMNIVIEW processes that can
    be expected to run CONCURrently. This program also
    evaluates the extent to which a "LIM 4.0" system supports
    multitasker operation and so can have diagnostic benefit.
    The archive includes a .DOC file, an application note
    concerning memory usage by DOS multitaskers in general,
    and a small file describing OMNIVIEW

WAITKEY.ZIP
    The .C and .EXE to a simple batch file utility (15K). The
    purpose of this program, which prompts for/verifies
    keyboard input with time-out, is to illustrate the
    differences between coding for straight DOS and for the
    OMNIVIEW Application Programmer's Interface (OAPI).

OVSTAT01.ZIP
    This 16K file contains the Turbo C source and executable
    to a continuous status display program. This program
    presents almost the same information as does the standard
    OVSTAT program that comes with OV except that it checks
    the state of the system and updates the display about
    once every two seconds. This program was written by Mike
    Toutonghi and was presented as part of an OMNIVIEW series
    that appeared in Radio and Electronics during 1989.
    Pressing <Esc> will terminate the program.

OVXIFC0.ZIP
    This 6.5K archive describes an interface to OMNIVIEW that
    is accessible to resident programs installed before the
    multitasker. The interface generates a series of
    "signals" that inform "external" programs of process
    events: Events such as task creation, context switches
    and foreground task changes.

    By utilizing this interface you could build programs that
    fed keystrokes to background processes, for instance.
    Another use would be to verify access to a global memory
    area set aside in upper memory for OMNIVIEW processes.
    Still another use would be to allow a "swappable TSR" to
    recognise when a multitasker was loaded on top of it.
    The interface has been used consistently in utility
    programs bundled with OMNIVIEW.

106BLT.ZIP
    This is a text bulletin describing this conference and can
    be used as a welcome screen.
---
 ■ EZ 1.22 ■

Date: 03-19-90 (14:30)              Number: 337 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 336
From: RICK KUNZ                       Read: 03-19-90 (15:59)
Subj: OV SUPPORT FILES              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>OMNIDOS0.ZIP
>DETECT00.ZIP

 Thanks for the uploads, Dennis. As with all Omniview support files,
these will be made available to first-time callers of Poverty Rock. I'm
also sending them to the INTELEC hub and The Sound Of Music hub so that
folks can request/download them from their respective hub.

Date: 03-19-90 (15:59)              Number: 338 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 333
From: DENNIS EDWARDS                  Read: --0 (22:17)
Subj: OmniView/PCBoard              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Thank you Dennis for the reply.  I will be looking into this more
│in the future, but I thank you for the quick reply.

You bet.
---
 ■ EZ 1.22 ■

Date: 03-20-90 (15:03)              Number: 339 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 337
From: DENNIS EDWARDS                  Read: 03-20-90 (18:14)
Subj: OV SUPPORT FILES              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>OMNIDOS0.ZIP
│>DETECT00.ZIP
│
│ Thanks for the uploads, Dennis. As with all Omniview support files,
│these will be made available to first-time callers of Poverty Rock. I'm
│also sending them to the INTELEC hub and The Sound Of Music hub so that
│folks can request/download them from their respective hub.

Thanks, Rick.
---
 ■ EZ 1.22 ■

Date: 03-20-90 (15:03)              Number: 340 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: new utility program           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I am uploading a new utility program as part of an update to the
documentation for OMNIVIEW's external interface. This file can be
found on Poverty Rock and (thanks to Rick) on the other usual
distribution channels as OVXIFC1.ZIP (10k).

BEEPER.COM is a TSR that takes up about 800 bytes of RAM and will
generate a tone every time a process is scheduled. Each process
has a different tone. The higher the tone the higher the console
number of the process that is running. By listening to the pitch
of the different tones, you will be able to determine which of
the available processes are actually running at any given time.
By listening to the pattern of the tones you will be able to tell
how long each is running and in what order.

This is probably not a program that you would want to add to your
AUTOEXEC.BAT file. But it can serve a useful purpose as a
diagnostic aid since it illustrates the scheduling patterns and
relative quanta of the active OMNIVIEW processes. It also
provides a workable example of how an external program can track
what OMNIVIEW is doing.
---
 ■ EZ 1.22 ■

Date: 03-20-90 (18:45)              Number: 341 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 340
From: RICK KUNZ                       Read: 03-21-90 (06:54)
Subj: NEW UTILITY PROGRAM           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

OVXIFC1.ZIP is available on the Rock, and will be file sent to the hubs
tonight, Dennis. Thanks again for the uploads of the Omniview API
programs!

Date: 03-21-90 (06:19)              Number: 343 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>This is just to see if the messages are going where they belong. Someon
>please respond to this so I know we are echoing this conference
>properly.

 This was addressed to ALL, and I'll reply to ALL, but it's a reply to
Rich Hinckley.

 Rich, your message was received as a receiver-only message from Sound
Of Music BBS. I am still getting *only* messages to ALL in this
conference from SOM, and they're all R/O when I receive them. The same
thing happens in the DISABLED conference. Sorry for the problems; I wish
Paul would fix whatever's wrong in the config there; everything else
works just fine except those few conferences.

Date: 03-21-90 (20:21)              Number: 344 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: NONE
From: DAVID CHRISTENSEN               Read: NO
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RH>This is just to see if the messages are going where they belong. Some
RH>please respond to this so I know we are echoing this conference
RH>properly.

 You made it to Sound of Music.
---
 * EMail 0318α
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-21-90 (23:30)              Number: 345 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 344
From: RICK KUNZ                       Read: NO
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  To: RICH HINCKLEY

> You made it to Sound of Music.

 And your reply was sent from SOM and received here as a r/o message.

Date: 03-22-90 (07:27)              Number: 346 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 341
From: DENNIS EDWARDS                  Read: 03-22-90 (08:16)
Subj: NEW UTILITY PROGRAM           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│OVXIFC1.ZIP is available on the Rock, and will be file sent to the hubs
│tonight, Dennis. Thanks again for the uploads of the Omniview API
│programs!

Just a nit picky note regarding the file descrip...

BEEPER, while zipped with the external interface docs (because the source is
included), is actually a general purpose diagnostic tool for OMNIVIEW setups.
If you ever wonder if/when your stuff is/is not running you can back out of
OMNIVIEW, load BEEPER, then reload OMNIVIEW and "see" what's going on behind
the video display.

Thanks, again, for sending this stuff on.
---
 ■ EZ 1.22 ■

Date: 03-22-90 (08:18)              Number: 347 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 346
From: RICK KUNZ                       Read: 03-23-90 (07:34)
Subj: NEW UTILITY PROGRAM           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>│OVXIFC1.ZIP is available on the Rock, and will be file sent to the hub

>Just a nit picky note regarding the file descrip...

 Here's what I posted on the description, Dennis: I'm not sure how I
should change that. Pick nits and tell me! :-)


OVXIFC1.ZIP     10244  03-20-90  Diagnostic tool for OMNIVIEW external
program interface programming w/ COM and ASM; Program beeps when a
new process is scheduled. Written, uploaded by Dennis Edwards, of
Sunny Hill Software.

Date: 03-22-90 (16:26)              Number: 348 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: 344
From: CLIFF WATKINS                   Read: NO
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>RH>please respond to this so I know we are echoing this conference
   And made it to the Intelec Net Hub as well. Enjoy this fabulous
conference Rich!

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 03-22-90 (19:52)              Number: 349 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: DAVID CHRISTENSEN               Read: 03-22-90 (22:36)
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

   From: RICK KUNZ                          Status: Private, Read

>  To: RICH HINCKLEY

> You made it to Sound of Music.

RK> And your reply was sent from SOM and received here as a r/o message.

 NOT AGAIN!!!!! Came here R/O.....Oh Paul?

                                      0 0
                                      ___
                                     /   \

   EMail 0318α
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-22-90 (22:36)              Number: 350 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 349
From: RICK KUNZ                       Read: NO
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

> NOT AGAIN!!!!! Came here R/O.....Oh Paul?

 Yup, sure did. Still a problem. I unprotect 'em -- if I get 'em --
which isn't usually, unless they're addressed to me, or to ALL. :-(

Date: 03-25-90 (02:33)              Number: 351 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: NONE
From: DAMIAN RUSSO                    Read: NO
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dave,
 Thanks for letting us know that the mail is getting thru alright. We
were having problems with this confere and one other. Glad to see things
are working better.
     Damian
---
 * Via ProDoor 3.1
 ■ QNet 2.03: SMARTNET 6092 Harred On-Line -  South Jersey Smartnet Hdquarters

Date: 03-25-90 (07:41)              Number: 352 / 572 (Echo)
  To: DAMIAN RUSSO                  Refer#: 351
From: RICK KUNZ                       Read: NO
Subj: CONFERENCE PROBLEMS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  To: DAVID CHRISTENSEN

> Thanks for letting us know that the mail is getting thru alright. We
>were having problems with this confere and one other. Glad to see thing
>are working better.

 Damian, your message came through as r/o here on the host board. Sorry,
but SOM's config is still shaky.

Date: 03-26-90 (07:51)              Number: 354 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 347
From: DENNIS EDWARDS                  Read: 03-26-90 (08:11)
Subj: NEW UTILITY PROGRAM           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>│OVXIFC1.ZIP is available on the Rock, and will be file sent to the hub
│...nits...
│OVXIFC1.ZIP 10244 03-20-90 Diagnostic tool for OMNIVIEW external
│program interface programming w/ COM and ASM; Program beeps when a
│new process is scheduled. Written, uploaded by Dennis Edwards, of
│Sunny Hill Software.

Just that it could also help diagnose problems where no external interface
stuff was in the picture ('cept BEEPER o' course). Not a biggy - anybody
following the conference will understand since I've made _such_ a point of
it.
---
 ■ EZ 1.22 ■

Date: 03-26-90 (18:47)              Number: 356 / 572 (Echo)
  To: DAMIAN RUSSO                  Refer#: NONE
From: DAVID CHRISTENSEN               Read: NO
Subj: Test                          Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DR> Thanks for letting us know that the mail is getting thru alright. We
DR>were having problems with this confere and one other. Glad to see thi
DR>are working better.

 No problem, we just have to get this fixed with Rick Kunz's node and
 SOM, seems that if a message is sent R/O its public, and a public is
 R/O. Oh well....I see my message pointers went up again, but with only
 your message in the conference.....L8r!

  EMail 0318α
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-29-90 (20:31)              Number: 357 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RICH HINCKLEY                   Read: HAS REPLIES
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

We at Harred have not received any messages in this conference. I can't
find any problem on our end. Coull someone reading this message in the
Omniview conference please respond to it. This may help me trace the
problem better. Thanks!


   Rich Hinckley - Co-Sysop - Harred On-Line - [phone]
---
 ■ DeLuxe 1·11 #1140  How do you spell Echomail? S-M-A-R-T-N-E-T!
 ■ QNet 2.03: SMARTNET 6092 Harred On-Line -  South Jersey Smartnet Hdquarters

Date: 03-29-90 (19:31)              Number: 359 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: 357
From: RICK KUNZ                       Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>We at Harred have not received any messages in this conference. I can't
>find any problem on our end. Coull someone reading this message in the
>Omniview conference please respond to it. This may help me trace the
>problem better. Thanks!

 Rich, your message came through here to Poverty Rock, but it was
originally an r/o message when received here, which I unprotected here
locally.  XYWrite worked this time, but Omniview's still not a go, it
appears.

Date: 03-30-90 (15:59)              Number: 360 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: NONE
From: DAVID CHRISTENSEN               Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

   Date: 03-29-90  (20:31)                  Number: 70     #1 of 2
     To: ALL                                Refer#: NONE
   From: RICH HINCKLEY                      Status: Public, Not Read
Subject: Testing                        Conference: 87 OMNIVIEW

RH>We at Harred have not received any messages in this conference. I can
RH>find any problem on our end. Coull someone reading this message in th

 Hi Rich, I haven't gotten any messages here either lately, seems that
 my pointers go up, but get no messages. I hear that QM door here at SOM
 though is spitting out messages for these conferences correctly
 though....I just don't feel like being a guinea pig again in QMail.
 Anyway, your message is here at SOM in OMNIVIEW.

 Good luck!

 Cheers, David.


   Saved Mar 30, 1990, at 3:23pm
---
 * EMail 0318α    From Bayport, Long Island NY     Relay R/O OK 32666
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-30-90 (18:35)              Number: 361 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 360
From: RICK KUNZ                       Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  To: RICH HINCKLEY

> though....I just don't feel like being a guinea pig again in QMail.
> Anyway, your message is here at SOM in OMNIVIEW.

 And yers came through here r/o. :-(

Date: 03-31-90 (09:07)              Number: 362 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: 357
From: DENNIS EDWARDS                  Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│We at Harred have not received any messages in this conference. I can't

Sorry, you're not seeing the traffic - but you're not alone, it appears. I am
able to see the posts after Rick (who sees his and messages to ALL) changes
the attributes. So if you get this...

Thanks for hanging in there.
---
 ■ EZ 1.22 ■

Date: 03-31-90 (12:00)              Number: 363 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: DAVID CHRISTENSEN               Read: 03-31-90 (16:16)
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

   From: RICK KUNZ                          Status: Private, Read
Subject: Testing                        Conference: 87 OMNIVIEW

>  To: RICH HINCKLEY

> though....I just don't feel like being a guinea pig again in QMail.
> Anyway, your message is here at SOM in OMNIVIEW.

RK> And yers came through here r/o. :-(

 aND IS r/o HERE TOO...aND MY cAPS lOCK KEY IS BROKEN.... jEEPERS...

   Saved Mar 31, 1990, at 11:33am
---
 * EMail 0318α    From Bayport, Long Island NY     Relay R/O OK 32666
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 03-31-90 (16:16)              Number: 364 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 363
From: RICK KUNZ                       Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>   Saved Mar 31, 1990, at 11:33am

 Yours came through OK this time, David. I hope this is an indication!

Date: 03-31-90 (20:51)              Number: 365 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: KEITH ELKIN                     Read: 04-04-90 (07:03)
Subj: OV conference                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hiya.. I was wondering where I can get ahold of Omniview...
I have a 286 with 1 meg on the motherboard and I have a DFI
memory expansion board with 2 megs on it... I want to be able
to run my BBS and also be able to run other software such as
Word Perfect and other software at the same time...
Can you help?  Thanks.. My voice # is (516)/266-5836
 -Keith


PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 03-31-90 (20:51)              Number: 366 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JOHN STEPHENS                   Read: 04-04-90 (07:03)
Subj: OV conference                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis,

I am very intersted in OmniView.  I heard a little bit about it, and
actually saw a friend with a copy.  I would like to know where I can get
a copy of it. Keith Elkins, who will probably be the message right after
mine is also interested ... (he is on node 2..)

Please send any info to me by mail..
PHOENIX BBS 520 Megs,99+Games! [phone]!
300 to 19,200 Baud! HST!- 24 Hours 7 Days/Week!
A member of INTELEC Network! (tm)

John Stephens
PHOENIX INC.
10374 Boca entrada blvd. Apt 229
Boca Raton, Florida 33428
USA

Thank You..

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 03-30-90 (22:31)              Number: 367 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: 357
From: DAVE CALMER                     Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Omniview conference please respond to it. This may help me trace the

Made it to Illinois on 03-30-90...

PCRelay:DANGRZN -> Intelec (tm) North Central SuperRegional
4.10ß9             The Danger Zone! [phone] Rock Island,Il

Date: 04-01-90 (19:59)              Number: 368 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: DAVID CHRISTENSEN               Read: 04-02-90 (16:41)
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

   From: RICK KUNZ                          Status: Public, Read

>   Saved Mar 31, 1990, at 11:33am

RK> Yours came through OK this time, David. I hope this is an indication

 AWnd yrs came public here too! Hope this is an indication of
 improvement....?!??

   Saved Apr 01, 1990, at 8:18pm
---
 * EMail 0318α    From Bayport, Long Island NY     Relay R/O OK 32666
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 04-01-90 (22:56)              Number: 369 / 572 (Echo)
  To: RICH HINCKLEY                 Refer#: NONE
From: CHUCK AMMANN                    Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>We at Harred have not received any messages in this conference. I can't
>find any problem on our end. Coull someone reading this message in the
-
You are now in Omniview.
---
 * Via ProDoor 3.1R SmartNet # 2011 Chuck's Attempt BBS 201 729-2602 Sparta NJ
 ■ RNet 1.04A: Chuck's Gig-Attempt "Attempting what seems the impossible"

Date: 04-02-90 (16:42)              Number: 370 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RICK KUNZ                       Read: (N/A)
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Looks like things are finally solved here for Smartnet! <cheer!>

Date: 04-02-90 (15:40)              Number: 371 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: NONE
From: CLIFF WATKINS                   Read: NO
Subj: Testing                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Don't you think all of that is a little over doing it?
   I didn't let that last message go out John, that is what happens when
nets share conferences, multiple tags. You (and me and us) will just
have to grin and bear it. It's life.....

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 04-03-90 (21:05)              Number: 372 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: ROBERT WALDINGER                Read: 04-03-90 (22:22)
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hello Rick,

RK>Looks like things are finally solved here for Smartnet! <cheer!>

       I really don't like to rain on your parade, but is the dis-Abled
conference ok?  Could you please explain briefly what was wrong with
OMNIVIEW?  I'm sure everybody here is pleased to see your constant
commitment, and appreciates all the time you put into fixing this
problem.  Thanks from all of us in the East!

                             True Blue
---
 ■ Via ProDoor 3.2ßR
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 04-03-90 (22:27)              Number: 373 / 572 (Echo)
  To: ROBERT WALDINGER              Refer#: 372
From: RICK KUNZ                       Read: NO
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DISABLED, I have seen no messages come through for several days. I don't
know if there are none which have come through to SOM or what; will
post a test msg in that one now.

 OMNIVIEW had the exact same problem; msgs were not coming through, or
were coming through as r/o when they were public at the origin.

Date: 04-03-90 (12:01)              Number: 374 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 370
From: CLIFF WATKINS                   Read: 04-05-90 (16:51)
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Looks like things are finally solved here for Smartnet! <cheer!>
   Glad it's been cleared up Rick. Now for the traffic.....

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 04-04-90 (11:57)              Number: 375 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: DAVID CHRISTENSEN               Read: 04-05-90 (16:51)
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RK>Looks like things are finally solved here for Smartnet! <cheer!>

 YYYEEEAAAHHH!!!!!!!!!!!!!!!!!!!!!

   Saved Apr 04, 1990, at 11:53am
---
 * EMail 0318α *    From Bayport, Long Island NY  *  Relay R/O OK 32666
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 04-04-90 (15:13)              Number: 376 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: ROBERT WALDINGER                Read: 04-05-90 (16:51)
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hello Rick,

> OMNIVIEW had the exact same problem; msgs were not coming through, or
>were coming through as r/o when they were public at the origin.

       How come OMNIVIEW is working, and dis-Abled isn't?  Perhaps you
should implement exactly what was done to the OMNIVIEW conferencem, into
the dis-Abled conference.

                           TRUE BLUE
---
 ■ Via ProDoor 3.2ßR
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 04-05-90 (07:37)              Number: 377 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: Well howdy                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

It is good to see that this conference is linked to SMARTNET now. I'd like to
thank all involved with the fix. If anyone out there sent me a message and
didn't get a reply, please try again.

I had posted a couple of general interest messages earlier and, if anyone is
interested, I can send them again. These included

- My "goal sheet" for the conference.
- A general description of the OMNIVIEW multitasker.
- A list of OMNIVIEW related files on the conference home board in Seattle:
  Rick Kunz' Poverty Rock BBS [phone]. The files should also be
  available on other boards using PCRelay software.

From time to time I hear from people expressing an interest the OMNIVIEW
conference. If you're carrying this conference and would like people in your
area to know that - please send me a message with your BBS' name, number,
speed, hours and (if applicable) any "new user" info that you want known.
I'll stick it in a database.
---
 ■ EZ 1.22 ■

Date: 04-05-90 (07:38)              Number: 378 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 366
From: DENNIS EDWARDS                  Read: NO
Subj: OV conference                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I am very interested in OMNIVIEW.
│Please send any info to me by mail..

We're sending you out a brochure. Thanks for your interest.
---
 ■ EZ 1.22 ■

Date: 04-05-90 (07:38)              Number: 379 / 572 (Echo)
  To: KEITH ELKIN                   Refer#: 365
From: DENNIS EDWARDS                  Read: NO
Subj: OV conference                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Hiya.. I was wondering where I can get ahold of Omniview...

The mailing address is:

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

[phone] - This number is good in USA & Canada, including WA

│I have a 286 with 1 meg on the motherboard and I have a DFI
│memory expansion board with 2 megs on it... I want to be able
│to run my BBS and also be able to run other software such as
│Word Perfect and other software at the same time...

I am not familiar with the DFI board. If it is LIM 4.0 hardware compatible
AND you have a Mono/Herc you can have 704K to run programs (736K with a CGA -
same old 640 w/ EGA/VGA). You can load OMNIVIEW into high memory (usually
D400-E000 is a good spot) and then it would only cost you 10-30K out of the
TPA. With a mono card and 590K free after your AUTEXEC runs - you would
probably have about 630K to run your apps. If you give the BBS 300K (since
you need to make interrupt driven programs non-swappable on anything less
than a 386) you would have about another 300K for your other programs. If you
can backfill your motherboard to 256K then you could have a half dozen 300k+
partitions running concurrently with your BBS - as long as none of them was
interrupt driven.

On a 386 (even an SX) with similar memory and video you could run 4 600K+
partitions concurrently. With 386MAX, any or all of them could be BBS nodes
so long as they were running with seperate IRQs and COM ports - and they
could all write directly to screen without bleeding through.
---
 ■ EZ 1.22 ■

Date: 04-05-90 (16:51)              Number: 381 / 572 (Echo)
  To: ROBERT WALDINGER              Refer#: 376
From: RICK KUNZ                       Read: NO
Subj: Hooray!                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>       How come OMNIVIEW is working, and dis-Abled isn't?  Perhaps you
>should implement exactly what was done to the OMNIVIEW conferencem, int
>the dis-Abled conference.

 I haven't changed a thing on this end, Rob.

Date: 04-06-90 (07:06)              Number: 383 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 378
From: JOHN STEPHENS                   Read: 04-07-90 (09:23)
Subj: OV conference                 Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>We're sending you out a brochure. Thanks for your interest.

Great!    I run a GAP BBS, and they've released a DesqView aware
version. I got a hold of the OMNIVIEW Information text file sent it to
them, and see if this works out good.. I've got 2 megs of memory, and
640 k on the mother board.. If I can run 2 nodes successful, I am sure
they will write a GAP BBS OmniView aware if all goes good.  Unless, it
is already OmniView aware from the DesqView Specs?

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
                   Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 04-09-90 (11:48)              Number: 384 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: exeinfo                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have uploaded a new OMNIVIEW utility in EXEINFO.ZIP (6k). This includes
EXEINFO.EXE and a small .DOC file for the utility.

Not all programs document how much RAM they need in order to run. EXEINFO can
be used to read an .EXE file's header (much like EXEMOD) and to display the
minimum load size of the program. This information can be used to set the
Required Memory size for partitions in which programs are run directly.

This program won't work with .COM files and, for .EXEs that perform a lot of
dynamic memory allocation from DOS or that use overlays, you may have to
increase the displayed value somewhat. It will always give you a
reasonable starting point for an .EXE if nothing else.
---
 ■ EZ 1.22 ■

Date: 04-09-90 (18:06)              Number: 385 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 384
From: RICK KUNZ                       Read: 04-10-90 (17:56)
Subj: EXEINFO                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks for the upload, Dennis -- EXEINFO is on its way to the network
hubs tonight.

Date: 04-15-90 (14:39)              Number: 388 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: JOHN STEPHENS                   Read: (N/A)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Please welcome PHOENIX BBS to the conference!
Thanks,
-= John =-

Someone mentioned sending me some information packet, Just thought I
would let them know I never got it.

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   PHOENIX BBS [phone] - Over 100 Doors!

Date: 04-16-90 (19:44)              Number: 390 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DAVE CALMER                     Read: (N/A)
Subj: More Questions...             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Well I was all set to order OMNIVIEW when the bottom fell out of one of
my drives delaying the purchase of the new computer. Todays question
is...can I run 2 PCB nodes under OMNIVIEW on a 286 (temporary). I have a
12 MHz 286 with 2 meg of ram and VGA. Thanks...

PCRelay:DANGRZN -> Intelec (tm) North Central SuperRegional
4.10ß9             The Danger Zone!! >>><<< [phone]

Date: 04-17-90 (08:47)              Number: 392 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: JOHN STEPHENS                   Read: (N/A)
Subj: SINCE..                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Since, Dave Calmer has his interest of PCB under two nodes..

There is a desqView aware version of GAP BBS.  Is there any relation of
DesqView and its operation and OmniView?

Well, if not.. then, can I run two nodes of GAP BBS, under OmniView.
I've got a 286, IBM PC/AT 12 Mhz, with 4 megs of memory using the
BOCARAM AT Card and 256k 100 ns chips.

Any help, or questions would be appricated! I want my second node up!  I
am going to dedicate a node to Messages, and my other node (1) to doors.
Which has about 100 online right now!

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-18-90 (16:23)              Number: 393 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 388
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Please welcome PHOENIX BBS to the conference!
│Thanks,

Welcome to the OMNIVIEW conference!

│Someone mentioned sending me some information packet, Just thought I
│would let them know I never got it.

That would be me.  We are sending you out another one to the address you
supplied.  I will also post a blurb here.

Sorry for the delay.
---
 ■ EZ 1.22 ■

Date: 04-18-90 (16:23)              Number: 394 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: omniview advertisement        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

OMNIVIEW Advertisement

OMNIVIEW (formerly TASKVIEW) is a preemptive multitasker for DOS
programs; this differentiates it from Microsoft Windows, Software
Carousel and others which do not provide true multitasking. You
CAN achieve true multitasking with Microsoft windows by running
multiple Windows '286 applications inside of OMNIVEW.

Unlike Quartedeck's DESQView, each OMNIVIEW process is a full
screen application - this makes OMNIVIEW both smaller and faster;
A very important consideration when running concurrent real time
applications (such as high speed communication programs or
industrial control systems) or when relying on memory hungry
device drivers and TSRs. Any TopView/DESQView aware application
will run as expected.

In contrast to VM/386, OMNIVIEW does not utilize (nor impose the
overhead of) multiple '386 virtual 8086 "machines". Each process
operates in a single virtual 8086 address space. Any device drivers
and/or TSRs loaded before OMNIVIEW are global to all processes.

The increasingly popular "dos extenders" may be fully utilized
inside any OMNIVIEW partion, allowing multiple concurrent
multi-megabyte applications.  While OMNIVIEW is compatible with
Quarterdeck's QEMM and other virtual control programs, we
recommend Qualitas' 386^MAX ($49.95) to get the maximum benefit
of OMNIVIEW on '386 systems; the professional version of this
program ($100) will also load device drivers into high memory,
maximizing the space available to run other programs.

SysOps quilify for a 35% discount off OMNIVIEW's $79.95 retail
price.

OMNIVIEW's features include:

-- As many as ten concurrently operating programs on a single
   machine.
-- Runs on all PC/AT/PS/2 machiness from 8088 to 80486 based
   systems.
-- True multitasking with dynamically configurable time slice
   duration (127 levels) and relative process priorities (15
   levnference is currently echoed on the Smartnet and
    Intellec networks.
---
 ■ EZ 1.22 ■

Date: 04-19-90 (08:35)              Number: 395 / 572 (Echo)
  To: DAVE CALMER                   Refer#: 390
From: DENNIS EDWARDS                  Read: NO
Subj: More Questions...             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Well I was all set to order OMNIVIEW when the bottom fell out of one of
│my drives delaying the purchase of the new computer.

Sorry to hear about the drive. I had a box catch fire a while back and know
how it goes...

│ Todays question is...
│can I run 2 PCB nodes under OMNIVIEW on a 286 (temporary). I have a
│12 MHz 286 with 2 meg of ram and VGA. Thanks...

Without LIM 4.0 hardware, OMNIVIEW is going to cost you about 60K out of the
TPA. On anything less than a '386 you'll need to make both nodes
non-swappable - so however much you give to each node will have "permanent"
impact on the system RAM. If you had 580K free after running your AUTOEXEC
then you would have about 260K for each node - which I think is the stated
minimum.

The way to max out your RAM in OMNIVIEW is to load a large DOS control
partition where, after spawning off the second node, you load PCB directly.
The OMNIDOS0.ZIP file, which Rick put on the net, has some tips on doing
this kind of thing.

If you want to run any of the larger doors you'll have to free up more RAM
before running OMNIVIEW or else beg a LIM 4.0 board (not just a driver). Of
course, w/ a '386 everything is virtual and life becomes much simpler.
---
 ■ EZ 1.22 ■

Date: 04-19-90 (08:35)              Number: 396 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 392
From: DENNIS EDWARDS                  Read: NO
Subj: SINCE..                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│There is a desqView aware version of GAP BBS.  Is there any relation of
│DesqView and its operation and OmniView?

Some things are similar, some aren't. The TopView calls that many programs
use to determine if a multitasker is installed, for instance, work the same
in OMNIVIEW. Our API is a lot different, however, so DESQView or Windows
_specific_ programs (ones that _have_ to load on top of something else)
won't work the same, if at all.

Programs that just change their I/O to be well behaved under a multitasker -
that is _aware_ programs - should work OK.  DETECT0.ZIP shows a generic way
to detect a multitasker.

│Well, if not.. then, can I run two nodes of GAP BBS, under OmniView.
│I've got a 286, IBM PC/AT 12 Mhz, with 4 megs of memory using the
│BOCARAM AT Card and 256k 100 ns chips.

I doubt that you'll have trouble running one node. Running two nodes depends
on how much RAM that each node has to have and I don't know how much room GAP
needs to do what you want. On anything less than a '386 you will have the
same problem as Dave: Any interrupt driven process will have to be fixed in
RAM. The trick is to give them as much room as you can.

Assuming that the BOCA card is LIM 4.0 hardware, then you should be able to
load OMNIVIEW in high RAM. It will typically fit between D400 and E000. This
will cut OMNIVIEW's TPA cost way down (no more than 30K and less than 10K in
many cases). Also if you have an MDA/Herc or a CGA then you can expand your
DOS TPA by 64K or 96K, respectively.

Once you know how much RAM you have (and how much you need) it's a simple
arithmetic problem to plug in the numbers and see if you can support two
nodes on the box you have.

│Any help, or questions would be appricated! I want my second node up!  I
│am going to dedicate a node to Messages, and my other node (1) to doors.
│Which has about 100 online right now!

Good luck. I know I haven't been all that specific in answering your
questions, but there are a lot of variables...it's usually easiest to just
try it out and then deal with the symptoms (if any).
---
 ■ EZ 1.22 ■

Date: 04-19-90 (21:28)              Number: 397 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DAVID CHRISTENSEN               Read: 04-21-90 (06:40)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)



 Mind sending me some info? (and demo if one exists?), As well do you
 offer student discounts? thanx!

 332 First Avenue
 Bayport, LI NY 11705-1304

 Cheers, David

 ≡ EMail 0318α ≡     From Bayport, Long Island NY   ≡   RIME R/O OK    ≡
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 04-20-90 (05:43)              Number: 398 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 393
From: JOHN STEPHENS                   Read: 04-21-90 (06:40)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Just incase the address came out wrong.


John Stephens (PHOENIX BBS)
10374 Boca Entrada Blvd. Apt 229
Boca Raton, Florida 33428
U.S.A.

How's that?

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-21-90 (08:03)              Number: 399 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 397
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│ Mind sending me some info? (and demo if one exists?), As well do you
│ offer student discounts? thanx!

Will send a brochure, come the workweek. No demo. We offer a 35% sysop
discount but none for students per se.
---
 ■ EZ 1.22 ■

Date: 04-21-90 (08:03)              Number: 400 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 398
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Just incase the address came out wrong...

That is the address we had, John. The info in my post is essentially what
you'll get in print, anyhow.
---
 ■ EZ 1.22 ■

Date: 04-21-90 (21:23)              Number: 401 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: FREDERICK KHONG                 Read: 04-24-90 (19:53)
Subj: PURCHASE                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I would like to obtain a copy of OmNiview. Please advise me on the terms
and conditions for purchase at sysop price. I'm a sysop of a bulletin
board in singapore. *Billboard BBS*.

I'm also a member of Interlink mail network. You can reach me at
Sleepy's hollow BBS. Enter the message in the main board of that BBS.

regards.

Date: 04-20-90 (23:00)              Number: 402 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 394
From: JOHN STEPHENS                   Read: 04-24-90 (19:53)
Subj: OMNIVIEW ADVERTISEMENT        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

How much does OmniView run for?

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-20-90 (23:04)              Number: 403 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 396
From: JOHN STEPHENS                   Read: 04-24-90 (19:53)
Subj: SINCE..                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


=> Good luck. I know I haven't been all that specific in answering your
=> questions, but there are a lot of variables...it's usually easiest to
=> try it out and then deal with the symptoms (if any).


You've helped me out quite a bit!  Many thanks!

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-22-90 (19:45)              Number: 404 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DAVID CHRISTENSEN               Read: 04-24-90 (19:53)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>│ Mind sending me some info? (and demo if one exists?), As well do yo

DE>Will send a brochure, come the workweek. No demo. We offer a 35% syso

 Thanx!

 Cheers, David

  EMail 0318α .      From Bayport, Long Island NY        PCRelay R/O OK
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 04-22-90 (20:00)              Number: 405 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 04-24-90 (19:53)
Subj: COPY FROM SALTAIR BBS         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, this msg appeared on the SaltAir PCBoard support BBS; thought
I'd post it over here in case you wanna steer him to an OV upgrade from
Taskview! <grin>. The name of the sender is well-known in shareware
circles.

Date: 04-16-90 (13:13)              Number: 4443 / 4509
  To: ALL                           Refer#: NONE
From: KENN FLEE                       Read: (N/A)
Subj: PRODOOR/TASKVIEW PROBLEM      Status: PUBLIC MESSAGE
Conf: DOOR (2)                   Read Type: GENERAL

I am running 2 nodes under taskview with PCB 14.2 and ProDoor 3.1.  My
problem is that when a caller attempts a ProDoor upload or download, and
that caller is on the node that is NOT currently displayed, the system
hangs in that node.  If I make that Taskview partition active
(Shft-Ctrl-1/2) then things start to go.  Apparently the system is
hanging when ProDoor opens a "window" to display the transfer info.
Any suggestions would be appreciated.   -Kenn-

Date: 04-22-90 (12:06)              Number: 406 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: JOHN KOFFLER                    Read: (N/A)
Subj: OMNIVIEW/BBS                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

To OmniView Developement Company,

I've got a few questions that I would like anyone/someone to answer.

Right now, I am running a DTK with 1 Meg of (boot up) memory on the
mother board. I've added 2 megs with a RAM card.  I would like to run a
Bulletin Board System up in the 2 Megs of RAM.  With the other 1 meg (on
board), I would like to be able to run programs, such as Word
Processors, Games, and *.GIF Viewing programs.

I would like to set a WildCat! board up and still have a computer for me
to use.  Is this possible?  If not, what do I need to change (other than
getting a 386 or 486 machine).  Any and all help would be greatly
appreciated.  I read in an above message that a SysOp would recieve 35%
off of the $79.95 price.  Are these numbers correct?  An if so, do I
have to set up ny board first and then get OmniView?  Thanks again...

                                               - John Koffler



PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-23-90 (13:02)              Number: 407 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JOHN KOFFLER                    Read: 04-24-90 (19:53)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Please send any and all information reguarding OmniView to the below
address.  I will be a SysOp as soon as I buy a DUAL STANDARD, and, of
course, a phone line.  Please send to:

        John Koffler
        c/o HEAVY METAL BBS
        P.O. Box 50075
        LightHouse Point, Florida 33074

  Many, many thanks.....

        - John

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-26-90 (12:37)              Number: 408 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 402
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW ADVERTISEMENT        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│How much does OmniView run for?

$79.95 sysops qualify for a 35% discount ($59.97). You'll need to send us
your BBS phone number.
---
 ■ EZ 1.22 ■

Date: 04-26-90 (12:37)              Number: 409 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 403
From: DENNIS EDWARDS                  Read: NO
Subj: SINCE..                       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│You've helped me out quite a bit!  Many thanks!

You bet.
---
 ■ EZ 1.22 ■

Date: 04-26-90 (12:37)              Number: 410 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 404
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│ Thanx!

You're welcome.
---
 ■ EZ 1.22 ■

Date: 04-26-90 (12:37)              Number: 411 / 572 (Echo)
  To: JOHN KOFFLER                  Refer#: 407
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Please send any and all information reguarding OmniView to the below
│address.

We're sending you a brochure in the mail. Additionally, you may wish to check
out the OV support files I have uploaded and/or reset your message ptrs to
catch some of the earlier conference messages. If your local BBS doesn't
support file xfer through the net you can get ahold of the support files by
calling Rick Kunz' BBS - the home board for this conference:

Poverty Rock BBS    [phone]

Please note that 3:30-6:15am is reserved for net mail xfer.

│ I will be a SysOp as soon as I buy a DUAL STANDARD, and, of
│course, a phone line.

In order to qualify for the sysop discount you must send us your (functional)
BBS number.

Good luck with your board.
---
 ■ EZ 1.22 ■

Date: 04-26-90 (12:37)              Number: 412 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 405
From: DENNIS EDWARDS                  Read: 04-26-90 (18:18)
Subj: COPY FROM SALTAIR BBS         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis, this msg appeared on the SaltAir PCBoard support BBS; thought
│I'd post it over here in case you wanna steer him to an OV upgrade from
│Taskview! <grin>. The name of the sender is well-known in shareware
│circles.

Taskview was before my time. While some things are the same in OV, a lot is
not. I draw a blank on this and can only suggest an upgrade to OV 4.13. I
think the upgrade cost for Taskview users is $25.

How to get this insightful info there?

│Date: 04-16-90 (13:13)              Number: 4443 / 4509
│  To: ALL                           Refer#: NONE
│From: KENN FLEE                       Read: (N/A)
│Subj: PRODOOR/TASKVIEW PROBLEM      Status: PUBLIC MESSAGE
│Conf: DOOR (2)                   Read Type: GENERAL
│
│I am running 2 nodes under taskview with PCB 14.2 and ProDoor 3.1.  My
│problem is that when a caller attempts a ProDoor upload or download, and
│that caller is on the node that is NOT currently displayed, the system
│hangs in that node.  If I make that Taskview partition active
│(Shft-Ctrl-1/2) then things start to go.  Apparently the system is
│hanging when ProDoor opens a "window" to display the transfer info.
│Any suggestions would be appreciated.   -Kenn-
---
 ■ EZ 1.22 ■

Date: 04-26-90 (12:37)              Number: 413 / 572 (Echo)
  To: JOHN KOFFLER                  Refer#: 406
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW/BBS                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Right now, I am running a DTK with 1 Meg of (boot up) memory...

I assume that the initial Meg is 640K conventional, 384K extended on a '286
momboard. I can't tell whether the other 2M are extended or expanded.
Probably the best use for extended memory, at least from OV's perspective, is
as a RAM disk. You can set the SWAP environment variable to point to that
drive and this will increase swapping speed. Since OV swaps on a process by
process basis, the resulting drive must be big enough to hold all your
swappable processes simultaneously: If you have three 300k swappable
processes and a 200k nonswappable process then you must have about 1M (300K *
3) reserved for the SWAP drive.

There on two kinds of concurrency supported by OMNIVIEW. Normal concurrency
is where a program is scheduled (on a preemptive, time sliced basis) whenever
its turn comes up: When this scheduling event occures depends on its priority
and quanta relative to the other current processes in the system. There are
16 priority queues (which can each hold ten processes) and each process may
have a quanta of 1-127 clock ticks. Scheduling events are considered on clock
tick. Omniview always trys to run a process with a higher priority if one is
available, if not, it will wait until the current process' quanta is expired
and then run the next highest priority process. A process that is waiting for
a system resource (such as a user's keystroke) will not be scheduled.

Interrupt concurrency is driven by hardware interrupts. On anything less than
a '386 system, interrupt driven processes must be nonswappable: That is,
fixed in the DOS Transient Program Area (TPA) - the room DOS has to run
normal programs, usually 640K. The last OV process to revector an IRQ is
given control of the CPU when that IRQ is generated. If no process has
revectored that IRQ it is passed on to the interrupt handler installed prior
to OV. With a '386 or later system and an appropriate memory manager
(currently only 386^MAX) these processes may run from EMS, provided they are
the last process to revecter a particular IRQ.

While on anything less than a '386 (with an appropriate memory manager)
interrupt driven processes can't run out of EMS. On these earlier systems,
EMS can still be useful, however. The things you can do with EMS depend on
the LIM hardware, the design of your motherboard, the type of video
adapter(s) in the system and the software you plan to run. With LIM 3.2 EMS
hardware (even with a LIM 4.0 driver), you can only do two things:

1) Swap processes using the EMS as a sort of fast RAM drive that will
overflow to some logical drive when it fills up.

2) Load the OMNIVIEW menu into the page frame. This takes 64K of EMS but only
9K out of the TPA. A few programs, such as Microsoft Windows and the
Lantastic network, do not like programs that run out of the page frame so
this may, or may not, be useful to you.

With LIM 4.0 EMS hardware and a LIM 4.0 driver you can also do the following:

1) Load OMNIVIEW into a 48K contiguous EMS (or XMS) block located somewhere
between the top of the video adapter (BIOS) and the bottom of the system ROM
BIOS. This is accomplished by configuring your memory manager to
perform/allow this allocation and then running OMNIHIGH.

2) "Topfill" from the top of conventional memory to the bottom of the first
video adapter's regen buffer. When an EGA/VGA (and some other "non-standard"
high resolution displays) the regen buffer starts at the 640K boundary and
this can't be done reliably. With an MDA or Hercules adapter you get an extra
64K (704K of DOS) and with a CGA you get an extra 96K (736K of DOS).

3) "Backfill" the motherboard. This requires that you remove conventional
memory from the motherboard and configure your memory manager to map EMS into
this vacant address space. The amount of conventional memory that you can
remove depends on the design of your system hardware and the assumptions made
by the BIOS Pre-Operation Startup Tests (POST). Consult you hardware
documentation for details.

Once you have accomplished the backfill, the size of the EMS block mapped
into the DOS TPA (Kbytes of backfill + Kbytes of topfill), will determine the
size of the largest swappable program for which normal concurrency is
supported. The number of normally concurrent processes you can have running
at one time will depend on you're free EMS. With 2M of EMS, an MDA (64K
topfill), 256K on the momboard (384K backfill), 580K free after AUTOEXEC is
run (644K free w/ topfill), and a 250K communications program running in
partition one, you would have:
        644K    total TPA
      -  12K    typical TPA impact from loading OMNIVIEW in high memory
      - 250K    space taken up by the non-swappable .COM program
      -------
        382K    remaining for normally concurrent processes
On all systems, EMS is community property. OMNIVIEW uses it to store/run
processes and these processses may use it to store data, overlays, etc. You
can limit the amount of EMS a process can use. If only one process were
allowed to use EMS and that use was limited to 500K, then you could run 3
( 1 + ((2048K - 64K - 48K -448K -500K) / 382K) ) normally concurrent
processes and have about 200K of EMS remaining.

I have uploaded a series of OMNIVIEW Application Notes which discuss these
issues in more detail. You may find them of interest.


















│ I read in an above message that a SysOp would recieve 35%
│off of the $79.95 price.  Are these numbers correct?  An if so, do I
│have to set up ny board first and then get OmniView?  Thanks again...

The numbers are correct. In order to qualify for the discount you must supply
us with a functional BBS number.
---
 ■ EZ 1.22 ■

Date: 04-26-90 (12:37)              Number: 414 / 572 (Echo)
  To: FREDERICK KHONG               Refer#: 401
From: DENNIS EDWARDS                  Read: 05-05-90 (06:51)
Subj: PURCHASE                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I would like to obtain a copy of OmNiview. Please advise me on the terms
│and conditions for purchase at sysop price. I'm a sysop of a bulletin
│board in singapore. *Billboard BBS*.

We'll need prepayment in US funds. Send your money order or VISA/MC
information (name, number, expiration date) by mail to:

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

Cost is $79.95 (with 35% sysop discount, $51.97) PLUS $10 for overseas
delivery. To qualify for the sysop discount, you'll need to include your BBS
phone number.

Thanks for your inquiry.
---
 ■ EZ 1.22 ■

Date: 04-26-90 (18:19)              Number: 415 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 412
From: RICK KUNZ                       Read: 04-27-90 (06:26)
Subj: TASKVIEW and OMNIVIEW         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Taskview was before my time. While some things are the same in OV, a lo
>not. I draw a blank on this and can only suggest an upgrade to OV 4.13.
>think the upgrade cost for Taskview users is $25.
>
>How to get this insightful info there?

 I'll post it as a reply to Kenn Flee on my next visit to the Saltair
system, Dennis. Will also send up the stock response on phone numbers,
etc.

Date: 04-27-90 (20:17)              Number: 416 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: CHUCK AMMANN                    Read: 04-30-90 (06:04)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>We're sending you a brochure in the mail. Additionally, you may wish to
-
>In order to qualify for the sysop discount you must send us your (funct
>BBS number.
Please forward the info on Omniview.  BBS info in Tag.  Thanks.
---
 * Via ProDoor 3.1R SmartNet # 2011 Chuck's Attempt BBS 201 729-2602 Sparta NJ
 ■ RNet 1.04U: Chuck's Gig-Attempt "Attempting what seems the impossible"

Date: 04-28-90 (05:56)              Number: 417 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JOHN KOFFLER                    Read: 04-30-90 (06:04)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks, I willl be looking for it...!!!

     - John

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 04-28-90 (12:48)              Number: 418 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RON HOSSACK                     Read: (N/A)
Subj: OV                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I would like to recieve a brochure about OV......

Solid Rock BBS  CACOL  [phone]     1200 - 19200  HST
Ron Hossack
3245 abbotsford
Riverside, CA  92503


PCRelay:LATENITE -> INTELEC (tm) Network, Freeport, NY
                    The Late Show! Riverside, CA 714-359-5624 HST

Date: 05-01-90 (06:26)              Number: 419 / 572 (Echo)
  To: CHUCK AMMANN                  Refer#: 416
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Please forward the info on Omniview.  BBS info in Tag.  Thanks.

OMNIVIEW Advertisement

OMNIVIEW (formerly TASKVIEW) is a preemptive multitasker for DOS
programs; this differentiates it from Microsoft Windows, Software
Carousel and others which do not provide true multitasking. You
CAN achieve true multitasking with Microsoft windows by running
multiple Windows '286 applications inside of OMNIVEW.

Unlike Quartedeck's DESQView, each OMNIVIEW process is a full
screen application - this makes OMNIVIEW both smaller and faster;
A very important consideration when running concurrent real time
applications (such as high speed communication programs or
industrial control systems) or when relying on memory hungry
device drivers and TSRs. Any TopView/DESQView aware application
will run as expected.

In contrast to VM/386, OMNIVIEW does not utilize (nor impose the
overhead of) the multiple '386 virtual 8086 modes. Each process
operates in a single virtual 8086 address space. All device
drivers and TSRs loaded before OMNIVIEW are global to all
processes.

The increasingly popular "dos extenders" may be fully utilized
inside any OMNIVIEW partion, allowing multiple concurrent
multi-megabyte applications.  While OMNIVIEW is compatible with
Quarterdeck's QEMM and other virtual control programs, we
recommend Qualitas' 386^MAX ($49.95) to get the maximum benefit
of OMNIVIEW on '386 systems; the professional version of this
program ($100) will also load device drivers into high memory,
maximizing the space available to run other programs.

SysOps quilify for a 35% discount off OMNIVIEW's $79.95 retail
price. OMNIVIEW's features include:

-- As many as ten concurrently operating programs on a single
   machine.
-- Runs on all PC/AT/PS/2 machiness from 8088 to 80486 based
   systems.
-- True multitasking with dynamically configurable time slice
   duration (127 levels) and relative process priorities (15
   levels).
-- Utilizes LIM 3.2, 4.0 and EEMS memory.
-- TSR's loaded before OMNIVIEW can be accessed by all processes.
-- TSR's loaded inside partitions act just as any other program,
   to remove them just kill the partition.
-- Supports all standard video adapters in all modes.
-- Loads in as little as 9K of conventional memory.
-- INCREASES memory available to run DOS applications by over 80K
   on some systems.
-- Keyboard macros and the ability to "cut and paste" among
   applications.
-- Easy to use menu interface.
-- Command line interface with a powerful collection of utility
   programs allows experienced users maximum flexibility.
-- Free technical support and much more.

The OMNIVIEW Application Programmer's Interface (OAPI), available
for the asking, has supported C, ASM and Turbo Pascal programmers
since 1986.  All OAPI applications have the ability to:

-- Create and eliminate sibling processes.
-- Suspend, activate and control sibling processes.
-- Send keystrokes to programs running in other partitions.
-- Send and receive various message objects.
-- Perform time sequenced, background events.
-- Establish shared data areas.
-- Create "invisible" customized user interfaces for integrated
   multitasking applications.
-- and much more.

Mailing Address:

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

FAX:    [phone] - Be sure to SPECIFICALLY ADDRESS all FAX
        messages to Sunny Hill Software.

VOICE:  [phone] - USA and Canada (including WA state).

BBS:    [phone]: Poverty Rock BBS

    This is a private board run by Rick Kunz. Rick has kindly
    provided space on the board for OMNIVIEW related files
    and this board serves as the OMNIVIEW support conference.
    This conference is currently echoed on the Smartnet and
    Intellec networks.
---
 ■ EZ 1.22 ■

Date: 05-01-90 (01:18)              Number: 420 / 572 (Echo)
  To: RON HOSSACK                   Refer#: 418
From: DAVE CALMER                     Read: NO
Subj: OV                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>I would like to recieve a brochure about OV......

I could use some info too, got to make up my mind soon!

The Danger Zone!! BBS
PO Box 6152
Rock Island, Il 61201-6154

PCRelay:DANGRZN -> Intelec (tm) North Central SuperRegional
4.10ß9             The Danger Zone!! >>><<< [phone]

Date: 05-02-90 (11:01)              Number: 421 / 572 (Echo)
  To: RON HOSSACK                   Refer#: 418
From: DENNIS EDWARDS                  Read: NO
Subj: OV                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I would like to recieve a brochure about OV......

OK, we'll send ya one!
Thanks for your interest.
---
 ■ EZ 1.22 ■

Date: 05-02-90 (13:07)              Number: 422 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 329
From: TIM FARLEY                      Read: 05-02-90 (17:52)
Subj: USE OF "NUL                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

[About problems re: PKZIP & redirection of NUL in OV]

TF>     PKZIP -Z WHATEVER.ZIP <NUL
TF>
TF>PKZip detects the redirection, and instead of waiting for input,
TF>it zap the comment field in that ZIPfile to nothing. But not in
TF>Omniview.  The above statement will cause an infinite wait a the
TF>Zip comment? prompt.

RK> Hmm, I didn't have that problem when I loaded OV and tried it,
RK>Tim. Tried both a top window of 300k+ and a smaller, 200k one and
RK>it worked just fine. I know this is probably a stupid question
RK>for a person of your expertise, but are you _sure_ pkzip has
RK>plenty of memory...?

Pretty sure.  Both of the windows I have set up are about 300K in
size, in order to run two PCBoard nodes with shelled protocols.

I have since removed the calls to PKZIP -T in ProDoor's batch
files to avoid the problem.  No really big deal, just a tad
surprising.

--Tim Farley

Date: 05-02-90 (13:07)              Number: 423 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 335
From: TIM FARLEY                      Read: 05-03-90 (06:28)
Subj: USE OF "NUL                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>What we will do is add a check to non-redirected devices to see if th
DE>device is NUL and, if so, treat it just like a file. This should give
DE>desired results to everyone.

Great, thanks!

It does seem a bit odd that PKZIP actually goes to the trouble of
writing data to the NUL device during a "test" operation---why
write it anywhere?  I will report this problem to PKWARE when I
get a chance.

Thanks for the reply, sorry I didn't get it earlier.

--Tim Farley

Date: 05-02-90 (13:07)              Number: 424 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 332
From: TIM FARLEY                      Read: 05-03-90 (06:28)
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

[About PCBoard nodes locking up under OV:]

TF>I have only installed a 16550AN UART on one partition so far, and tha
TF>partition seems to lock up every three hours or so.
TF>
TF>Is there something special I need to do with 16550's under OV?

DE>This is an odd problem. There is nothing special you need to do
DE>for different kinds of UARTS under OMNIVIEW.
DE>
DE>If the problem shows up again, you should be able to determine if
DE>OMNIVIEW has dropped the ball by looking to see if the IRQ for
DE>the troubled port is still enabled....

I will keep that in mind.  In the frantic fiddling after finding
this problem, I seem to have found the solution.  Not exactly
sure whether it was this specifically, or a combination of
factors, but I found that when I changed the time slice each
partition was getting from the default 4 ticks to half that (2
ticks per slice), that the problem seemed to go away.

I will keep your advice in mind if it reoccurs.

DE>Since the troubled partition accepts console input, it does not
DE>seem that you have a memory shortage.

Yes, I am pretty sure everything is OK in that respect---PCBoard
uses about 220K or so, plus maybe 64K more for shelled protocols.
I have 300K free in each partition.

DE>Have you tried just killing the "dead" node and bringing it back
DE>up? You would have to get to DOS in the other node and run SPAWN
DE>or OPEN to restart it.

I never actually tried that, but I will definitely do so if it
occurs again, to see if that works.

--Tim Farley

Date: 05-02-90 (13:07)              Number: 425 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 419
From: TIM FARLEY                      Read: 05-03-90 (06:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>The OMNIVIEW Application Programmer's Interface (OAPI), available
DE>for the asking, has supported C, ASM and Turbo Pascal programmers
DE>since 1986.

I assume that "available for the asking" means free?  <grin>

Regardless, I am very interested in this API kit.  What do I have
to do to get a copy?

--Tim Farley

Date: 05-02-90 (18:15)              Number: 427 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 05-03-90 (06:28)
Subj: OMNIVIEW API STUFF            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis, is the API programmer's stuff distributable via BBS? Have I had
that here in the past? (Don't seem to now).

In any event, if it is postable, or you wish to put a file up for
downloading, I can post it with or without password, so that selected
individuals can download it. Let me know.

Date: 05-03-90 (06:29)              Number: 428 / 572 (Echo)
  To: DAVE CALMER                   Refer#: 420
From: DENNIS EDWARDS                  Read: NO
Subj: OV                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I could use some info too, got to make up my mind soon!

It's on the way!
Thanks for your interest.
---
 ■ EZ 1.22 ■

Date: 05-03-90 (10:18)              Number: 429 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 423
From: DENNIS EDWARDS                  Read: 05-07-90 (14:51)
Subj: USE OF "NUL                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>What we will do is add a check to non-redirected devices to see if th
│Great, thanks!

You bet.

│It does seem a bit odd that PKZIP actually goes to the trouble of
│writing data to the NUL device during a "test" operation---why
│write it anywhere?  I will report this problem to PKWARE when I
│get a chance.
│
│Thanks for the reply, sorry I didn't get it earlier.

Yes, I thought it odd myself.
Don't worry about not responding to my response (to...), the traffic got
messed up pretty bad here for awhile it seems. I'm just glad ya got it!
---
 ■ EZ 1.22 ■

Date: 05-03-90 (10:18)              Number: 430 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 424
From: DENNIS EDWARDS                  Read: 05-07-90 (14:51)
Subj: DUAL NODE PCBOARD & OV        Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│[About PCBoard nodes locking up under OV:]
│TF>I have only installed a 16550AN UART on one partition so far, and tha
│TF>partition seems to lock up every three hours or so.
│...I found that when I changed the time slice each
│partition was getting from the default 4 ticks to half that (2
│ticks per slice), that the problem seemed to go away.

Hmmm. Well that would make the processes "cycle" sooner - so if there were
work being done by the proc outside of the interrupt handler and that job's
not getting run soon enough was causing some kind of mutual lock out...
I dunno. I'm glad it's working.
---
 ■ EZ 1.22 ■

Date: 05-03-90 (10:18)              Number: 431 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 425
From: DENNIS EDWARDS                  Read: 05-07-90 (14:51)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>The OMNIVIEW Application Programmer's Interface (OAPI), available
│DE>for the asking, has supported C, ASM and Turbo Pascal programmers
│DE>since 1986.
│I assume that "available for the asking" means free?  <grin>

;-) ya gotta be registered and ya gotta ask - then it's free.

│Regardless, I am very interested in this API kit.  What do I have
│to do to get a copy?

Just call [phone] and request it.
---
 ■ EZ 1.22 ■

Date: 05-03-90 (10:18)              Number: 432 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 427
From: DENNIS EDWARDS                  Read: 05-03-90 (14:18)
Subj: OMNIVIEW API STUFF            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis, is the API programmer's stuff distributable via BBS? Have I had
│that here in the past? (Don't seem to now).

I've never sent you the API, Rick. As far as it's being distributable via
BBS: Well, sorta. Right now you'ld need the entire API to really get a good
handle on how things work. That pretty well fills up a 360K floppy. A second
disk is also provided that includes the files you have on the Rock right now.

As it stands, the docs for the interface functions are pretty specific toward
the C library. Though the descriptions of the way any particular API function
works is the same regardless of how it is invoked (and though the source to
all the library functions are included), some find it difficult to translate
"C'isms" to their own application language. We intend to expand the
documentation text file to include the semantics of the other languages. We
also want to add (more) example programs for the other two languages.

We are considering expanding the .ASM interface (which is essentially just an
OV detection routine, a series of function number equates and a couple of
interrupt emulation macros) to simplify taking advantage of the HLL
interfaces in MASM 5.1, TASM, etc. If anyone has any particular feelings
about this, I would be happy to hear of them.

With this done then each language API would stand on its own and people could
download a much smaller, application language specific, file. I've been
holding off uploading until that's done.

│In any event, if it is postable, or you wish to put a file up for
│downloading, I can post it with or without password, so that selected
│individuals can download it. Let me know.

There is no reason for the API _not_ to be downloadable, I guess, it's just
something I haven't facilitated as yet.

I think it's very interesting that you have that "password" capability.
Though it isn't something we have a use for right now, I will certainly keep
it in mind and possibly beg it's use at a later date. Thanks for offering.
---
 ■ EZ 1.22 ■

Date: 05-03-90 (10:18)              Number: 433 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: OAPI function summary         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Below is an excerpt from the OMNIVIEW Application Programmer's Interface
(OAPI) documentation found in \C\C_OAPI.DOC on disk one of the OAPI. This
lists all functions in the C OAPI library and describes the added
functionality available to programs that rely on any of OMNIVIEW's
programming language interfaces.

 OAPI Functions by Catagory
----------------------------

 Initialization
----------------
tvversion    - Returns OMNIVIEW version, inits interface   (TVVER.C)

 Process Control Functions
---------------------------
tvcreateproc - Create a concurrent process                  (TVCREATP.C)
tvcurtofg    - Make current process foreground              (TVCURFG.C)
tvcurphndl   - Return caller's process handle               (TVCURPCB.C)
tvfgphndl    - Return foreground process handle             (TVFGPCB.C)
tvfreemem    - Return free memory and swapping space        (TVFREEM.C)
tvgetswap    - Get swappability of a process                (TVGETSWP.C)
tvgetallinfo - Return all active processes' information     (TVGTINFA.C)
tvgetoneinfo - Return one active process' information       (TVGTINFO.C)
tvkillcur    - Kill the current process                     (TVKILLC.C)
tvkillproc   - Kill a specific process                      (TVKILLP.C)
tvmaxprocs   - Return the maximum number of processes       (TVMAXP.C)
tvnumtofg    - Make a specific process foreground           (TVNUMFG.C)
tvnumprocs   - Return the number of active processes        (TVNUMP.C)
tvsched      - Release remainder of time slice              (TVSCHED.C)
tvsetkill    - Prevent this process from being killed       (TVSETKIL.C)
tvsetname    - Set the name of a process                    (TVSETNAM.C)
tvsetpri     - Set priority and process state of a process  (TVSETPRI.C)
tvsetswap    - Set the swappability of a process            (TVSETSWP.C)
tvsuspendcur - Suspend the current process                  (TVSUSPND.C)
tvswapin     - Swap in a process from disk or expanded RAM  (TVSWAPIN.C)
tvwakenum    - Wake a process which suspended itself        (TVWAKEN.C)

 Keyboard Device Functions
---------------------------
tvgetphandle - Get process handle for a console number      (TVGPHNDL.C)
tvgetpnum    - Get console number for a 32 bit handle       (TVGPNUM.C)

 Screen Device Functions
-------------------------
tvautoupdate - Makes screen update automatic from virtual   (TVAUTOUP.C)
tvgetupdate  - Returns the screen update status             (TVGETUPD.C)
tvpostvirt   - Posts the virtual screen to the real screen  (TVPOSTV.C)
tvsetupdv    - Sets screen update to virtual screen         (TVSETUPV.C)
tvsetupdr    - Sets screen update to real screen            (TVSETUPR.C)
tvvidaddr    - Returns the OMNIVIEW virtual screen address  (TVVIDADR.C)

 Object Queue Device Functions
-------------------------------
tvchkmsg     - Check for a message from a process or a device (TVCHKMSG.C)
tvwaitmsg    - Wait for a message from a process or a device  (TVWTMSG.C)
tvsendnw     - Send message to a process, don't wait        (TVSENDNW.C)
tvsendwait   - Send message to process, wait til received   (TVSENDWT.C)
tvsendtime   - Send a timed message to a process            (TVSENDTM.C)
tvflushtime  - Flush timed messages for a process           (TVFLSHTM.C)

 Global Variables
------------------
_tventry                                                    (TVVER.C)
    This contains the far address of the OMNIVIEW function
    dispather.
_objqinstalled                                              (TVOQDATA.C)
    This is a boolean variable indicating that the object
    queue is installed.
_objqdevaddr                                                (TVOQDATA.C)
    This contains the far address of the object queue device.
---
 ■ EZ 1.22 ■

Date: 05-02-90 (14:56)              Number: 434 / 572 (Echo)
  To: DAVE CALMER                   Refer#: 420
From: RON HOSSACK                     Read: NO
Subj: OV                            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

yeah...I know Sal uses it in Seattle and has had nothing but good things
to say about it.....

PCRelay:LATENITE -> INTELEC (tm) Network, Freeport, NY
                    The Late Show! Riverside, CA 714-359-5624 HST

Date: 05-11-90 (06:21)              Number: 435 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: HAS REPLIES
Subj: New Home Board Number         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The phone number of the home board for this conference (and one of the BBSs
offering the OMNIVIEW support files) has been changed - please make a note
of it. ;-)

The new Seattle number for Poverty Rock BBS (node 1) is:

        [phone]

This number change reflects Rick Kunz' move to another part of town
as well as his support for multiple nodes (which should make your getting
online here much easier). Please note that the time between 3:30am-6:15am is
reserved for network node traffic. The least busy period seems to be between
9am and noon.

Take care.
---
 ■ EZ 1.22 ■

Date: 05-11-90 (07:02)              Number: 436 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 435
From: RICK KUNZ                       Read: --0 (08:42)
Subj: New Home Board Number         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


Thanks for the plug, Dennis. I also wanted to add that the OMNIVIEW
support file area is available to first-time callers of Poverty Rock;
validation is required for full access otherwise.

Date: 05-15-90 (18:18)              Number: 437 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: TIM FARLEY                      Read: 05-16-90 (09:10)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Had a problem occur this afternoon when a Critical Error (INT
24h) handler happened in one partition.

As you know, we run two nodes of PCBoard under OmniView.  Here is
the salient info:

     Hyundai Super-286 Clone, Mono card, 640K RAM
     PC-DOS 3.3
     OmniView 4.13 (running OMNIHIGH)
     AST RAMPAGE 286 Plus EMS 4.0 Card with 512K of RAM on it.

     PCBoard 14.2/E3
     MarkMail 1.44
     PKZIP 1.01

We have two ST-251 40Meg drives in the system.  The first
partition is a 32 Megger managed by DOS, the second (D:) is 8
meg (the remainder on the first drive) and the third (E:) is the
whole second drive.  D: and E: are managed by Disk Manager,
DMDRVR.BIN.  We also have the Super-PC-KWIK disk cache program
loaded, with the /N+ parameter as recommended by the READ.ME
file.

We've been running in basically this same configuration for two
and a half months.

The two nodes are run from batch files, so Node 1 is task 1, Node
2 is task 2, and there are no other tasks in the system.  With
OMNIHIGH and careful tuning, both tasks have about 300K free
memory.

What occurred was this:

There were users on both Node 1 and Node 2. Node 2 was currently
the "foreground" partition.  The user on Node 2 was doing a new
files scan in PCBoard, which only involves files & programs on
the C:\ partition.

The user on Node 1 was in MarkMail building a mail packet to
download.  MarkMail had just finished building the packet files
(the last entry in the caller log was MarkMail's report of the
packet size) and had just dropped out to its batch file to allow
PKZIP to pack the files up.  PKZIP must have been running,
because after the crash I found a 0-byte .QWK file, and a
temporary file that PKZIP had created.  The way we have MarkMail
set up, all the scratch work gets done on the D:\ partition,
which has nothing else on it but scratch dirs.

Apparently, there were "bad clusters" on our D: partition that we
were not aware of.  PKZIP hit one while building the .QWK file.
This caused a critical error, which PKZIP does NOT trap, so the
infamous Abort, Retry Ignore prompt came up.

Here's the rub:  the Abort, Retry Ignore prompt came up in the
FOREGROUND partition (it should have been in the background) and
somehow crashed/disabled the background partition in which it
occurred.  We found the system with the critical error prompt in
the middle of the foreground caller's output on the screen.  Both
callers had dropped carrier because of the system lockup, but
PCBoard had not recycled on either node.

When we hit "Abort" at the prompt, it accepted it, and PCBoard in
the foreground partition got control, saw the dropped carrier,
and correctly recycled with no further problem!

I dropped the foreground node (node 2) to DOS and ran OVSTAT, and
it showed no indication of a partition 1 existing.  It was gone.
But partition 2, despite having a critical error prompt come up
into it from the other partition, seemed fine!

Is this a bug in OmniView, an interaction in our software, or
what?

--Tim Farley

Date: 05-17-90 (07:58)              Number: 438 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 437
From: DENNIS EDWARDS                  Read: 05-21-90 (15:41)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Had a problem occur this afternoon when a Critical Error (INT
│24h) handler happened in one partition....
│What occurred was this:
│
│There were users on both Node 1 and Node 2. Node 2 was currently
│the "foreground" partition.  The user on Node 2 was doing a new
│files scan in PCBoard, which only involves files & programs on
│the C:\ partition.
│
│The user on Node 1 was in MarkMail building a mail packet to
│download.... PKZIP must have been running,
│because after the crash I found a 0-byte .QWK file, and a
│temporary file that PKZIP had created....
│Apparently, there were "bad clusters" on our D: partition that we
│were not aware of.  PKZIP hit one while building the .QWK file.
│This caused a critical error, which PKZIP does NOT trap, so the
│infamous Abort, Retry Ignore prompt came up.
│
│Here's the rub:  the Abort, Retry Ignore prompt came up in the
│FOREGROUND partition (it should have been in the background) and
│somehow crashed/disabled the background partition in which it
│occurred.  We found the system with the critical error prompt in
│the middle of the foreground caller's output on the screen.  Both
│callers had dropped carrier because of the system lockup, but
│PCBoard had not recycled on either node.
│
│When we hit "Abort" at the prompt, it accepted it, and PCBoard in
│the foreground partition got control, saw the dropped carrier,
│and correctly recycled with no further problem!
│
│I dropped the foreground node (node 2) to DOS and ran OVSTAT, and
│it showed no indication of a partition 1 existing.  It was gone.
│But partition 2, despite having a critical error prompt come up
│into it from the other partition, seemed fine!
│
│Is this a bug in OmniView, an interaction in our software, or
│what?

That's a feature, Tim. The logic behind it is as follows:

    A. DOS is not reentrant.
    B. There is only one copy of DOS
    C. Critical Errors occure while _inside_ DOS.
    D. The DOS Critical Error handler waits on keyboard input before
       returning the response code.
    E. Nothing returns from a DOS call in which there is a critical error
       until after a response code is available.
    F. Since DOS is not reentrant and there is only one copy of DOS in the
       machine only one partition can ever access DOS at any given time _AND_
       that process must return from DOS before another process can be made
       current.

As a result, whenever a critical error occures, the machine "hangs" out
waiting for the operator to tell it what to do.

Why the machine stopped is noted above. The reason that the foreground
process continued after pressing the 'A'bort key is that there was nothing
wrong with it. The reason why zip died is because you told DOS to kill it.
I am not able to explain why killing zip also killed the proc: This should
only happen when the program that dies is the controlling (initial) program
inside that partition. I just conducted a variety of tests on the critical
error code and it seems to be working as it should.

The reason that you got the background proc's critical error message on the
screen is because we turn off screen virtualization during critical errors
so you can see "why" the machine is not "doing" anything. Where this message
shows up depends on the logical cursor position of the background program
experiencing the critical error. What it looks like depends on the state of
the video adapter. We used to hide these critical errors through the screen
virtualization process, but people complained of inexplicable system hangs
(often caused by something as simple as an open drive door) so we don't do
it anymore.

It isn't possible to change the process context in the middle of a Critical
Error. I will see if there is something we can do to increase the information
content of the default Critical Error message. Assuming what I've said so far
makes sense, what would it have taken to make this picture clear to you at
the outset?
---
 ■ EZ 1.22 ■

Date: 05-15-90 (12:38)              Number: 439 / 572 (Echo)
  To: RICK KUNZ                     Refer#: NONE
From: JOHN STEPHENS                   Read: 05-18-90 (00:39)
Subj: NEW HOME BOARD NUMBER         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Just a question, what is the latest version of OmniView?

Can it be purchased commercially, or store?

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 05-18-90 (09:10)              Number: 440 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 439
From: DENNIS EDWARDS                  Read: NO
Subj: NEW HOME BOARD NUMBER         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Just a question, what is the latest version of OmniView?
│Can it be purchased commercially, or store?

OMNIVIEW is at 4.13.
You can find it in some stores and in some mail order houses, or you can buy
direct by calling:

        [phone]

List price is $79.95. If you run a board, give the order desk your BBS number
and get a 35% discount.

Thanks for your interest.
---
 ■ EZ 1.22 ■

Date: 05-19-90 (12:06)              Number: 441 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RICK KUNZ                       Read: 05-20-90 (07:48)
Subj: OV AND PCB BLEEDTHROUGH       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis: This small interchange occurred on Bob Blacher's PCBoard
and I thought it might bear reposting here in the OV conference.

>Date: 05-17-90 (23:01)        SYSOP Number: 1220
>  To: SYSOP
>From: BILL WALSH
>Subj: 14.5 BETA
>
>Bob.  How do you deal with the bleed through on your omniview nodes?
>Even with the screen turned off in the background, the clock and the
>activity line of the call waiting screen still bleed to the foreground

>
>Date: 05-18-90 (09:50)        SYSOP Number: 1221
>  To: BILL WALSH                    Refer#: 1220
>From: SYSOP                           Read: NO
>Subj: 14.5 BETA
>
>Add /T (TopView compatibility) to all of your OmniView command lines.
>PCBoard 14.5 will stop "bleeding" at that point and also give back a
>ton of CPU cycles while it's idling.

Date: 05-17-90 (18:01)              Number: 442 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: JOHN STEPHENS                   Read: (N/A)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I've got 2 megs of Expanded memory.

How does OmniView run in High memory?

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS - [phone] - 19,200 HST ■

Date: 05-19-90 (05:03)              Number: 443 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DAVE BIGGS                      Read: (N/A)
Subj: OmniView upgrade.             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I have a 4.10 (I think it is) version of OmniView.  I was wondering what
it cost to upgrade to the newest version.  I have also heard about a
"PROGRAMERS" verion of OmniView, is there such an animal?
---
 * Via ProEdit 3.1 Looking for Vanna's brains...did you find them
 ■ RNet 1.05C: Smartnet Node #407-101 - The Black Cauldron - [phone]

Date: 05-21-90 (07:32)              Number: 444 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 441
From: DENNIS EDWARDS                  Read: 05-21-90 (19:39)
Subj: OV AND PCB BLEEDTHROUGH       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis: This small interchange occurred on Bob Blacher's PCBoard
│and I thought it might bear reposting here in the OV conference.
│...
│>Add /T (TopView compatibility) to all of your OmniView command lines.

Thanks Rick. I think you'll find the same thing holds true for many programs
claiming to be multitasker aware.
---
 ■ EZ 1.22 ■

Date: 05-21-90 (15:41)              Number: 445 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: TIM FARLEY                      Read: 05-22-90 (12:54)
Subj: Bizarro file redirection      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I guess it's my month for weird happenings with OmniView.

Last Friday, we came in to find our BBS in a "crashed" state.
When someone tried to log in, PCBoard reported that the main
board needed repacking, zero messages available, etc etc.

I looked at the main message base file, and it was severely
truncated (it was like 14K long, when it should have been several
megabytes).  Inside of it was not a message base at all, but the
redirected output from the BBS itself!

Apparently, an abnormal disconnect (carrier lost?) or something
happened on node 1 at around midnight, because the caller log has
a break at that point.  The first node accepted no further
callers until we reset it in the morning.

Then, a caller hit node 2 about 3:00 a.m. or so, using Robocomm
to fetch his mail from our MarkMail door.  His session on the BBS
actually seemed to go fairly smoothly, but get this:  when he hit
the main board prompt, screen output from PCBoard started being
redirected into the USERNET.DAT file!   Then, after Robocomm
issued its first command at the prompt, the redirection continued
into the MAIN board message base.

This redirection included output from PCBoard, MarkMail, DSZ, the
batch files in between, etc.  I couldn't even conceive of how to
generate such a redirection, as it was my distinct impression
that most of these programs wrote through the BIOS to do screen
I/O when running under a multitasker (which is how I have them
set up---they do not bleed through).  However, there were some
ANSI color sequences in the MarkMail output, so I assume that
program does write to the console through DOS.

The only thing I can conclude is that somehow, a crash on Node 1
caused OmniView to lose track of file handle contexts from the
two nodes, and what should have been going to the CON device on
one node, was actually going into other files opened on the other
node, or even that same node.  (The two files that were trashed
by the redirection are files that are almost always open at that
point in a BBS session.  USERNET.DAT is how multiple PCBoard
nodes communicate with each other during a session, and MAIN is
the main board message base).

After restoring the main message base and repacking, everything
has run smoothly since.

I hope you can shed some light on this one...

--Tim Farley

Date: 05-22-90 (12:54)              Number: 446 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 442
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I've got 2 megs of Expanded memory.
│
│How does OmniView run in High memory?

You need to allocate a contiguous 48K block of EMS/XMS in between your video
adapter and your system ROMs. Running OMNIHIGH.COM in place of OMNIVIEW.EXE
will load the multitasking kernal into this upper memory block. Note that
this is not the (64K - 16 bytes) of extended memory at 100000h absolute which
is controlled by HIMEM.SYS.
---
 ■ EZ 1.22 ■

Date: 05-22-90 (12:54)              Number: 447 / 572 (Echo)
  To: DAVE BIGGS                    Refer#: 443
From: DENNIS EDWARDS                  Read: NO
Subj: OmniView upgrade.             Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I have a 4.10 (I think it is) version of OmniView.  I was wondering what
│it cost to upgrade to the newest version.  I have also heard about a
│"PROGRAMERS" verion of OmniView, is there such an animal?

To upgrade to 4.13 you just need to call [phone] and request it.

There is only one version of OMNIVIEW. But it does have an Application
Programmers Interface (OAPI). These libraries are documented on disk and all
source to the lib functions are included. Languages supported are ASM, C, and
Turbo Pascal (3 and 4+). To get this, you call the number above. All the
utility programs included with OV (including the menu) make use of the OAPI.
---
 ■ EZ 1.22 ■

Date: 05-22-90 (16:42)              Number: 448 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: MIKE STROCK                     Read: HAS REPLIES
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hello.  I am attempting to set up two nodes of PC Board 14.2 /E3 running
on an XT with 2 megs of EMS 3.2 memory.  I guess I'm not familiar enough
with Omniview (v4.10) to get things to work.  Could someone here leave
me their setup for a two node configuration.  I've got one node set up
in c:\pcb and one node set up as c:\pcb2.  Followed the directions in
the PC Board manual, but I can't seem to get node #2 up and running.
I've got 589k free, after running share.  I've allocated 280k for each
node inside omniview.  i guess what I really need to know is how to
switch to get the second node up and running once I see the call waiting
screen for node 1.  The control-Leftshift doesn't bring any information
up on switching tasks.  I'd also like to load omniview into high memory
(EMS 3.2) but when I run omnihigh, it says I must be using omniview 4.10
or above.  I used to think I was pretty computer literate, but getting
this to work (I should say trying) makes me feel pretty stupid.

   I'm running prodoor 3.1 (registered) as the only door.

   Thanks,

      Mike Strock
       ButtonWare Tech Support BBS [phone] 4pm-8am daily Pacific.

Date: 05-22-90 (19:25)              Number: 449 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 448
From: RICK KUNZ                       Read: 05-26-90 (09:36)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Mike: One thing which might help, I was just told that the 14.5 Overlay
version of PCBoard will run in about 180k. With that LIM 3.2, this may
be about the only way to go; at least it might solve that problem on
your end. Give it a try.

Date: 05-23-90 (17:22)              Number: 451 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 438
From: TIM FARLEY                      Read: 05-24-90 (10:44)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

[On critical errors being bleeded through to foreground...]

TF>Had a problem occur this afternoon when a Critical Error (INT
TF>24h) handler happened in one partition....

DE>That's a feature, Tim. The logic behind it is as follows:

DE>As a result, whenever a critical error occures, the machine
DE>"hangs" out waiting for the operator to tell it what to do.

Yes, now that you have explained that, it does make sense.

DE>It isn't possible to change the process context in the middle of
DE>a Critical Error. I will see if there is something we can do to
DE>increase the information content of the default Critical Error
DE>message. Assuming what I've said so far makes sense, what would
DE>it have taken to make this picture clear to you at the outset?

It would be nice if there were a paragraph in the manual or
READ.ME that explained this feature.  Like in chapter 5 with that
other miscellaneous "gotcha" stuff.

I have a critical error handler called FATAL, written by Sam
Smith of Prodoor fame.  It does several things, including:

     * jazzes up the output
     * displays additional info such as the "locus" and
       "suggested action" that DOS can tell you
     * automatically takes the suggested action in 30 seconds
       if there is no keyboard input.

FATAL is mainly designed for unattended setups (like BBS's) that
cannot afford to be hung up in an Abort, Retry, Ignore prompt
(especially when said prompt was caused by a Network error that
might well be a temporary condition) with no operator present to
press "R" for retry.

How it does it's job is by grabbing the INT 24h vector back every
timer tick (yes, I know, it's ugly) so that even though DOS
replaces that vector with it's own every time a program
terminates, FATAL retains control.

I used to run FATAL under our BBS before we went to OmniView.  I
wasn't sure whether they would be compatible with each other.

Question 1:  Would it be appropriate to load FATAL with OmniView?
If so, would I load it within each partition, or outside of
OmniView as a global TSR?

Question 2:  If it were loaded globally, do you think that it
could benefit by making it OmniView aware using the API outlined
in OVXIFC1.ZIP?   If so, I may be willing to do this (FATAL comes
with source code).

My suggestion would be to build an "internal" Critical Error
handler in OmniView, much like FATAL, that could pop up in the
foreground and say "A Critical error has happened in Process
#x...".  Or perhaps make it something like COMMOUSE that the user
could load or not on their own preference/need.

--Tim Farley

Date: 05-23-90 (17:22)              Number: 452 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 444
From: TIM FARLEY                      Read: 05-24-90 (10:44)
Subj: OV AND PCB BLEEDTHROUGH       Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>Add /T (TopView compatibility) to all of your OmniView command lines.

DE>Thanks Rick. I think you'll find the same thing holds true for
DE>many programs claiming to be multitasker aware.

In previous versions of PCBoard, you would use an option "/BIO" to
make it use BIOS writes.  It's nice to know the 14.5 version
supports the faster TopView style screen writes....

--Tim Farley

Date: 05-24-90 (10:45)              Number: 453 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 445
From: DENNIS EDWARDS                  Read: 05-30-90 (16:47)
Subj: Bizarro file redirection      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I guess it's my month for weird happenings with OmniView...
│Last Friday, we came in to find our BBS in a "crashed" state...
│I looked at the main message base file, and it was severely
│truncated...
│Apparently, an abnormal disconnect (carrier lost?) or something
│happened on node 1 at around midnight...
│Then, a caller hit node 2 about 3:00 a.m. or so, using Robocomm
│to fetch his mail from our MarkMail door.  His session on the BBS
│actually seemed to go fairly smoothly, but get this:  when he hit
│the main board prompt, screen output from PCBoard started being
│redirected into the USERNET.DAT file!...
│This redirection included output from PCBoard, MarkMail, DSZ, the
│batch files in between, etc.  I couldn't even conceive of how to
│generate such a redirection, as it was my distinct impression
│that most of these programs wrote through the BIOS...
│The only thing I can conclude is that somehow, a crash on Node 1
│caused OmniView to lose track of file handle contexts from the
│two nodes, and what should have been going to the CON device on
│one node, was actually going into other files opened on the other
│node, or even that same node....
│
│After restoring the main message base and repacking, everything
│has run smoothly since.
│
│I hope you can shed some light on this one...

Nothing anybody 'round here has ever heard of before - certainly nothing that
we can make sense of, except as a catastrophic system crash. If the
"something" that happened in node 1 was more severe than it seemed and
OMNIVIEW/DOS/BIOS data/Devices were overwritten in the paroxysm then who
knows what could happen? Since (appearently) BIOS output was going to files,
it seems that whatever combination of things that were "lost track of"
included more than just file handles (which we don't alias anyway). I'm Sorry
it happened to ya, but I can't tell you why.
---
 ■ EZ 1.22 ■

Date: 05-24-90 (15:30)              Number: 454 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 446
From: TIM FARLEY                      Read: 05-29-90 (07:28)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>Note that this is not the (64K - 16 bytes) of extended memory at
DE>100000h absolute which is controlled by HIMEM.SYS.

Speaking of which, is there any thought that there might be a
future version of OMNIVIEW that *can* use the "High Memory Area"
via HIMEM.SYS?  That sure would help alot on 286
systems.....heck, even on 386 systems if you want to load your
TSR's in the Upper Memory Blocks that OMNIHIGH uses now.

--Tim Farley

Date: 05-24-90 (15:30)              Number: 455 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 448
From: TIM FARLEY                      Read: 05-26-90 (09:36)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

MS>Hello.  I am attempting to set up two nodes of PC Board 14.2 /E3
MS>running on an XT with 2 megs of EMS 3.2 memory.

That's nearly the config we run on the SemWare Support BBS at
[phone] right now, though we have an AT class machine, and less
EMS available.  Plus our EMS is 4.0 compatible.

I thought OMNIHIGH needed true hardware-compatible EMS 4.0 (not 3.2) to
work, but Dennis can correct me on that.

We use both OMNIHIGH, and we made sure that we only have a Monochrome
adapter in the system.  This allows Omniview to "backfill" past 640K to
make for larger partitions.  We are able to get two 303K partitions this
way, big enough to run PCBoard with most external protocols.

First, I set all the PCBoard and ProDoor environment variables I can in
our AUTOEXEC.BAT.  That helps avoid "out of environment space" problems.
Also, set an environment variable called NODE to 1 in the AUTOEXEC, just
to default it:

     SET NODE=1

Then I invoke from the end of AUTOEXEC.BAT, a batch file called LOADBBS
that loads Omniview, and spawns the first node.  It looks like this:

  ECHO OFF
  rem LOADBBS.BAT -- Load multiple PCBoard nodes under Omniview
  EXIT
  C:
  CD \OV
  SET JUNK=THIS IS A JUNK VARIABLE TO HOLD SPACE IN THE ENVIRONMENT
  OMNIHIGH /D:SCR:FAST /C:2 /PB /M:296 %COMSPEC% /E:512 /C NODE1.BAT
  :DONE

Basically we do an EXIT to keep from accidentally running this inside a
shell.  Then we change to the OmniView directory and fire up OMNIHIGH.

We set /C:2 because I found it runs a little smoother.  /PB makes sure
the background node gets equal priority to the foreground one.  /M:296
sets the memory.  Then from %COMSPEC% (just a tricky way of finding
COMMAND.COM) on just invokes the NODE1 batch file.

NODE1.BAT looks like this:

  ECHO OFF
  rem NODE1.BAT -- Load NODE1 (and spawn NODE2) of PCBoard
  SPAWN /D:SCR:FAST /PB /C:2 /M:296 %COMSPEC% /E:512 /C NODE2.BAT
  set NODE=1
  rem reclaim environment space
  SET JUNK=
  C:
  CD \PCB%NODE%
  BOARD

We just use SPAWN to fire up NODE2.BAT with the same parameters that
NODE1.BAT got on the OMNIHIGH command line.  Then we make sure NODE=1 in
the environment, and get rid of the JUNK variable to clear out some
space.

NODE2.BAT looks just the same, but it just eliminates the SPAWN line,
and it does a SET NODE=2 to set the node number correctly.

Then we change to \PCB1 (%NODE% gets substituted to 1 at run time) and
run BOARD.BAT.  I use %NODE% like this all through the batch files to
customize directory and file names for each node.  That way I avoid
having one copy of everything for each node.

We left most of the .EXE files, etc., in the \PCB directory just as in
the normal setup.   We added this directory to the path.  Then we
created \PCB1 and \PCB2 to act as "working" directories for the two
nodes.  As you can see, by using the NODE environment variable, you can
easily make your batch files "generic".  Here is the minimum set of
files I found you have to keep in \PCB1 and \PCB2:

     PCBOARD.DAT        Data file for PCBOARD configuration
     CALLWAIT.SCR       Image of screen PCB shows between calls
     REMOTE.SYS         "Batch" file run on remote drop to DOS
     EVENT.SYS          "Batch" file run during the event
     PCBSG.BAT          Protocol batch files
     PCBSY.BAT             "       "     "
     PCBSZ.BAT             "       "     "
     PCBRG.BAT             "       "     "
     PCBRY.BAT             "       "     "
     PCBRZ.BAT             "       "     "
     PCBERR.OLD         Used by protocol batch files
     PCBOARD.SYS        Created by PCBoard
     PRODOOR.           Door file for Prodoor
     MARKMAIL.          Door file for MarkMail

this keeps the system very clean.  I found that it couldn't hurt to mark
most of the .EXE files you share between nodes as "Read ONly", this
helps avoid Share violations if two nodes try to run the same program at
the same time.

(continued in next message....)

Date: 05-24-90 (15:30)              Number: 456 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 448
From: TIM FARLEY                      Read: 05-26-90 (09:36)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

(continued from previous message)

Our BOARD.BAT file looks like this:

  echo off
  set PRODEBUG=
  rem NOTE: Each node MUST have a different DSZLOG setting!
  set DSZLOG=C:\PCB%NODE%\$door.log
  c:
  cd \pcb%NODE%
  rem a unique prompt, so we won't get confused when at DOS
  prompt [Node %NODE%] $p $t$h$h$h$h$h$h $g
  if exist remote.bat rename remote.bat remote.sys
  if exist event.bat rename event.bat event.sys
  if exist door.bat del door.bat
  if exist endpcb del endpcb
  pcboard
  if exist remote.bat remote
  if exist door.bat door
  if exist event.bat event
  if exist endpcb goto end
  board
  :end
  c:\ov\switchto %NODE%
  pcbnoise
  set prompt=Type EXIT to reload PCBoard$_[Node %NODE%] $p $g
  %COMSPEC%
  board

Note a few things.  First, note how we use %NODE% to customize the
PROMPT settings, and also the DSZLOG setting.  We also use it to execute
a SWITCHTO command that switches a node to the foreground when it drops
to DOS.  (PCBNOISE is just a little program I wrote that makes an
annoying sound effect when run, so that we can set the board to drop to
DOS for maintenance, then walk away and come back when we hear the
sound).

Now remember that under OmniView, you cannot let the top level shell
exit, or the partition closes.  Normally when you drop a node to DOS,
BOARD.BAT exits.  To avoid that here, we set the prompt to a reminder
to type EXIT to return to PCBoard, then we execute %COMSPEC%, which just
fires up a subsidiary copy of COMMAND.COM.  Then when that exits, the
file just cycles around and runs itself.

By clever use of %NODE% in this and other batch files, we find that we
only have to have one version of most of the key files, not one for each
node as most of the CDC documentation notates.  For instance, the batch
file we run the MarkMail door from looks the same on both nodes:

  @ECHO OFF
  REM MARKMAIL(.BAT) is based on MM-DOOR1.BAT (low memory MarkMail)
  IF EXIST MM-EXT.BAT DEL MM-EXT.BAT
  :TOP
  C:
  CD \PCB\MM
  MARKMAIL C:\PCB\MM\MM%NODE%.CFG
  IF NOT EXIST MM-EXT.BAT GOTO DONE
  %COMSPEC% /C MM-EXT
  GOTO TOP
  :DONE
  C:
  CD \PCB%NODE%
  IF EXIST EVENT.BAT EVENT
  BOARD

There is also at least one utility I know of for PCBoard (RNet by Robert
Vostreys) that will specifically look for a NODE environment variable in
order to determine what node it is running on.

The way we fire things up here, the node number equals the
OmniView partition number, equals the PCBoard node number, equals
the COM port number.  PCBoard Node 1 runs in OmniView partition
number 1 on COM1.  That makes things much easier.

I hope that helps some.

--Tim Farley

Date: 05-24-90 (19:28)              Number: 457 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 456
From: RICK KUNZ                       Read: 05-30-90 (16:47)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks for posting your configs for OV and PCBoard, Tim! I know this
will help others who ask the same question from time to time, and I'm
sure Dennis appreciates having a "live one" posted here, too!

Date: 05-25-90 (07:35)              Number: 458 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 451
From: DENNIS EDWARDS                  Read: 05-30-90 (16:47)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│[On critical errors being bleeded through to foreground...]
│DE>That's a feature, Tim. The logic behind it is as follows:
│
│Yes, now that you have explained that, it does make sense.
│
│It would be nice if there were a paragraph in the manual or
│READ.ME that explained this feature.  Like in chapter 5 with that
│other miscellaneous "gotcha" stuff.

OK. We can do that.

│I have a critical error handler called FATAL, written by Sam
│Smith of Prodoor fame.  It does several things, including:
│
│How it does it's job is by grabbing the INT 24h vector back every
│timer tick (yes, I know, it's ugly) so that even though DOS
│replaces that vector with it's own every time a program
│terminates, FATAL retains control.
│
│Question 1:  Would it be appropriate to load FATAL with OmniView?
│If so, would I load it within each partition, or outside of
│OmniView as a global TSR?

Since a tick is a rather long time - in terms of instruction cycles, anyway -
its hard to say what would happen. Perhaps adding an int 21h filter that
tracked the current PSP would be beneficial - though it would be very busy,
especially during a context switch. If you put such a thing in, you would
probably also want to put a boolean flag in the int 21h handler which just
jumped on if a proc was being switched. This flag could be turned on by the
"proc is getting switched out" code and turned off by the "proc is being
switched in code".

If the current crit err vector was pointing to your handler during the
critical error event - then it should work OK.

If you wanted to take the easiest route, you might want to use the OAPI
(versus the "external interface") and replace the timer tick handler with a
message handler - just have OV wake you up every tick and check vectors.
That would be the closest approximation to the "pure DOS" condition. You
would, of course, run this version inside each proc where you needed it.
You could also have it get it's console number and display that as well.

│Question 2: If it were loaded globally, do you think that it
│could benefit by making it OmniView aware using the API outlined
│in OVXIFC1.ZIP? If so, I may be willing to do this (FATAL comes
│with source code).

The external interface will only let you know when a "process" context
changes - it does not signal you of changes in the state of the thread within
that process (DOS's current PSP does that). Since you want to have the crit
err handler active in the background as well as the foreground, it doesn't
really do you all that much good. The process time-slices are based on the
same clock rate you would be triggered from anyway.

The one benefit you _would_ get (which is not really a minor one) is that you
would be able to tell which process was current when the crit err code was
activated.

│My suggestion would be to build an "internal" Critical Error handler

Well we sort of have that now. Every time you enter int 21h we are the
current crit err handler. That is how we know to suspend multitasking.
However, since we appreciate the work people go to to write spiffy crit err
handlers that people _expect_ to see, we always call the real crit err
handler and then take its advice.

No matter what we do, there is a chance it will fail - a program could easily
pop up a window on top of our "in proc number" message. Probably the best way
to go is to use some global variation of FATAL as you suggest. Track the
current proc and add a line in the border (or in the Locus display) that
identifies the ailing proc.

There are couple things to keep in mind. The first proc created is the system
proc - rather than the first partition. Keep track of its handle and ignore
anything that happens when it is current. Also, console numbers are reused so
you have to track deaths as well as births, context changes, and the
startup/shutdown of OV.

Finally, the code that turns off screen virtualization is actually within
OMNIVIEW's BIOS video interrupt handler. To get the virt screen turned off
you must make a BIOS call before poking your screen into the vid regen
buffer (at least on a '386). A cursor move or attribute change will do.

Good luck and please keep us posted on what you do with this. It is, I think,
a good thing and I would encourage you to save me the work of doing it. ;-)
---
 ■ EZ 1.22 ■

Date: 05-25-90 (07:35)              Number: 459 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 448
From: DENNIS EDWARDS                  Read: 05-26-90 (09:36)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Hello.  I am attempting to set up two nodes of PC Board 14.2 /E3 running
│on an XT with 2 megs of EMS 3.2 memory.... Followed the directions in
│the PC Board manual, but I can't seem to get node #2 up and running.
│I've got 589k free, after running share.  I've allocated 280k for each
│node inside omniview.

I don't think you've enough (or the right type of) memory to create two nodes
of this size. When loaded in low memory OMNIVIEW takes about 60K. This leaves
about (590-60) = 530K. This means that largest partitions you can bring up
will be about 265K. What you should be seeing (if you try to spawn a second
280K proc) is a "Not enough memory or virtual devices." message.

│ i guess what I really need to know is how to
│switch to get the second node up and running once I see the call waiting
│screen for node 1.

The way to maximize your available memory is to use a batch file which, run
from the OMNIVIEW command line opens a second partition (which runs a similar
batch file). When OMNIVIEW is run, it always tries to open an initial
partition. The options that it uses are essentially the same as those for
OPEN and SPAWN (though it does have a couple more switches that have global
affect). Here is an example:

C>OMNIVIEW /m:265 trythis.bat

This should open a 260K partition and load COMSPEC to run the TRYTHIS.BAT
file. This first .BAT should open a second equivalent partition that runs a
.BAT and then starts up the first PCB node:

REM: TRYTHIS.BAT

OVSTAT
SPAWN /m:265 trythis2.bat
cd\first_PCB_node's_directory
...

Note that the second line, the one that executes the OVSTAT program, is there
only for diagnostic purposes. The memory size given for the first partition
should be the same as the "Largest Free Block": If it is not you then you
must subtract the latter from the former and subtract this difference from
the values supplied for the '/m:' parameters in _both_ the OMNIVIEW and the
SPAWN command lines - and then start over.

The SPAWN line is the one that makes a place for the second node. Note that
its memory value is the same one that you gave OMNIVIEW. Also note that the
.BAT you run in this partition will be the almost the same as the one which
ran it. The only differences between the two .BATs is that the second
doesn't spawn anything and starts the second node instead of the first. In
other words:

REM: TRYTHIS2.BAT

cd\second_PCP_node's_directory
...

Obviously, you need to write the .BAT file before you tell OV to run them.
:-)

│ The control-Leftshift doesn't bring any information
│up on switching tasks.

You're right. It isn't supposed to - though it's not a bad idea. However, all
those little niceties take up memory...

│ I'd also like to load omniview into high memory
│(EMS 3.2) but when I run omnihigh, it says I must be using omniview 4.10
│or above.

Sorry, that version (4.13 is current) had a silly bug in the error messages:
It should have said "Could not allocate EMS or Upper Memory Blocks."

In order to use OMNIHIGH you have to have either LIM 4.0 (software AND
hardware) or mappable XMS memory. When run high, OV takes about 10-30K
(9-15K is typical). It also allows you to fill in to the bottom of your
video adapter which - if you have a Herc or MDA, can give you another 64K or
another 96K if you have a CGA (you get no help from EGAs/VGAs - and, because
the memory is slow, you probably don't want any anyhow).

Without a '386 or later, you'll have to keep your COM programs non-swappable,
even with a LIM 4.0 card.

│ I used to think I was pretty computer literate, but getting
│this to work (I should say trying) makes me feel pretty stupid.
│   I'm running prodoor 3.1 (registered) as the only door.

I'm sorry you're having a tough time. This stuff is rather complicated and
does take a big toll on system resources. And I'm sure that dumb message
wasn't helping you out much, either.

A couple of things you might want want to keep in mind is that each process
that you create executes linearly - just think of them as separate, tiny
little DOS machines which share everthing. The number and size of the
"machines" you can create depends on the amount and type of resources you
have as well as the type of work you want them to do.

One thing that confuses some people is that the menu system _is_ a processes,
rather than part of OMNIVIEW itself. That is why you can switch back to it
and start up other stuff - sort of like typing exit from DOS and returning to
a menu shell. The difference, in the case of OMNIVIEW, is that our menu shell
lets the other programs keep running.

Since the shell is a process it takes up room in RAM - so whatever help you
get from it is not free. If you want the simplicity of the menu then you can
run OVSETUP and select "Expanded Memory Operation" from the menu options -
but that still costs 9K out of the TPA and 64K of EMS.

Since you have no "control proc" created in the .BATs I showed you above -
you have to create all the needed sibling processes _before_ you run
anything in proc #1. Otherwise you'll be looking at the application program
screen with no where else to go.

Perhaps the overlaid versions Rick mentioned can help you out with your RAM
crunch.

Good luck.
---
 ■ EZ 1.22 ■

Date: 05-30-90 (17:45)              Number: 460 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 454
From: DENNIS EDWARDS                  Read: 06-04-90 (17:33)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>Note that this is not the (64K - 16 bytes) of extended memory at
│DE>100000h absolute which is controlled by HIMEM.SYS.
│Speaking of which, is there any thought that there might be a
│future version of OMNIVIEW that *can* use the "High Memory Area"

It is something we've thought about but, at this time, no actual work is
underway. I concede your points. Unfortunately, there are several drawbacks
(from our point of view anyway) to using the HMA - and those issues, in
themselves, require a major revision to overcome.
---
 ■ EZ 1.22 ■

Date: 05-30-90 (17:45)              Number: 461 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 456
From: DENNIS EDWARDS                  Read: 06-04-90 (17:33)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks for the post, Tim. You're perfectly correct in saying OMNIHIGH needs
needs LIM 4.0 mappable hardware - although it will also work on systems where
the XMS driver can control this mapping as well (should you encounter one).
I liked your %NODE% variable - that is a clean trick that beats the CONSNUMB
method when you have a consistent setup.

│Now remember that under OmniView, you cannot let the top level shell
│exit, or the partition closes.  Normally when you drop a node to DOS,
│BOARD.BAT exits.  To avoid that here, we set the prompt to a reminder
│to type EXIT to return to PCBoard, then we execute %COMSPEC%, which just
│fires up a subsidiary copy of COMMAND.COM.  Then when that exits, the
│file just cycles around and runs itself.

You could avoid using exit commands by loading COMMAND in resident mode
(without the /C option) and then using SENDKEYS to "type in" the initial
commands in the new partition (which is how the menu shell's "remain in DOS
after end" option works). This method requires a convolution if the
partitions need to be non-swappable since you can't send keys directly from
the OMNIVIEW command line and so must start the first proc with a /C argument
to COMMAND. Note that, by default, each proc gets a 160 byte copy of the
"master" environment when it is created.

--------

C>copy con file1.bat
rem: spawn second partition with a resident command.com
spawn /m:300

rem: set %node% for second proc
sendkeys 2 set node=2\r

rem: start up the first proc, load second node, and die.
sendkeys 2 file2.bat\r
^Z

--------
C>copy con file2.bat
rem: see which partition we're running in, if #1 then #2 is already up
if %node%==1 goto TWO_PROCS_ACTIVE

rem: wait for the partition that was started on the OV command line to die
WAITPROC 1

rem: spawn resident COMMAND for first node (reuse first console number 1)
spawn /m:300

sendkeys 1 file2.bat\r

TWO_PROCS_ACTIVE:
rem: from here on out just start up PCB as usually - but skip the extra
rem: shells, this will save you a little bit of space and hassle
^Z

-------

An alternate method - one that would keep you from "EXIT"ing out of any of
the procs (though KILL and <CTRL><ALT><DEL> would still work) - would be to
rename autoexec.bat and use the /P option for command. In this case you could
set the environment specifically for each proc based on the errorlevel from
CONSNUMB rather than globally. The only other changes in FILE2.BAT would be
to use %COMSPEC% /P and then copy back the actual AUTOEXEC.BAT contents after
spawning the first node (which will be in partition one but will be the third
process created).

--------

C>copy con file1.bat

rem: duplicate autoexec.bat - only needs to be done once
copy \autoexec.bat \autoexec.tru

rem: cause file2.bat to run instead of the "real" autoexec.bat
copy file2.bat \autoexec.bat

rem: spawn second partition with a "parent" command.com
spawn /m:300 %COMSPEC% /P /E:384
...

--------

Thanks again for your contributions.
---
 ■ EZ 1.22 ■

Date: 05-31-90 (13:35)              Number: 462 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 458
From: TIM FARLEY                      Read: 06-04-90 (02:34)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>│[On critical errors being bleeded through to foreground...]
DE>│DE>That's a feature, Tim. The logic behind it is as follows:
DE>│
DE>│Yes, now that you have explained that, it does make sense.

Today a critical error occurred again.  After I hit "A" to abort,
one node appeared to recycle, then both nodes were locked up
tighter than a drum.  Even the dreaded three-fingered-salute
wouldn't work.

I am at the stage where I think we are perhaps having more
fundamental hardware problems on this machine---this time it was
a "Sector not found" error on the hard disk partition in
question, and I could not find any problems with that partition
after running Norton's DiskTest program.

This partition that keeps invoking the critical error handler is
managed by Disk Manager.  Is there anything special we should be
doing to use DMDRVR.BIN with OmniView?


I'll see if I can fool around with FATAL when I have some time,
and come back if I have further questions.  Thanks for the tips.

I called you folks about getting the OAPI kit mailed to me,
haven't seen anything in the mail just yet, though.

--Tim Farley

Date: 06-03-90 (20:21)              Number: 463 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 459
From: MIKE STROCK                     Read: 06-04-90 (17:33)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Tim & Dennis:

    Thank you very much for your replies  about  my  PCBoard
problems.  The  batch  files and explanations should help me
out alot.  I'll let you know what happens.  I've got an  EMS
4.0 card which I may just drop in to the PC,  which may help
me out.

  Tim,
  Thanks for the batch files.  I think it  is  just  what  I
need  to  get going.  I greatly appreciate the help.  Thanks
to you to Rick,  I got the Overlay version of  14.5/E3,  and
this should help too.

   Mike

---
 ■ EZ 1.26 ■

Date: 06-03-90 (23:04)              Number: 464 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 463
From: RICK KUNZ                       Read: 06-05-90 (08:23)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>to you to Rick,  I got the Overlay version of  14.5/E3,  and
>this should help too.

 Yep, that should give you much more usable RAM to work with, even if
you don't put in the LIM 4.0 card. I hear that each node requires less
than 200k now, so multitasking should be feasible for many more boards.

Date: 06-04-90 (18:35)              Number: 465 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 460
From: TIM FARLEY                      Read: 06-06-90 (10:48)
Subj: OMNIVIEW using HMA            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

TF>Speaking of which, is there any thought that there might be a
TF>future version of OMNIVIEW that *can* use the "High Memory Area"

DE>Unfortunately, there are several drawbacks (from our point of
DE>view anyway) to using the HMA - and those issues, in themselves,
DE>require a major revision to overcome.

As a friend of mine is fond of saying, "I heard that!"

Yeah, it would be a bit more complex than just relocating the
code up there like OMNIHIGH does now.  There are certain types of
data that just aren't kosher to put in the HMA, like DOS Disk
buffers, certain types of interrupt handlers, etc.

Barring a version of OV that could "live" up there, it still
would be nice if it could make use of that memory---perhaps as
scratch space.  Or it could allocate TopView "shadow" screens up
there.  Or anyone of a number of things that take real RAM or EMS
right now.

--Tim Farley

Date: 06-04-90 (18:35)              Number: 466 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 461
From: TIM FARLEY                      Read: 06-06-90 (10:48)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>You could avoid using exit commands by loading COMMAND in
DE>resident mode (without the /C option) and then using SENDKEYS to
DE>"type in" the initial commands in the new partition

Neat trick---I'll have to look at possibly using that.  My main
problem is I barely have enough RAM to run the two partitions I
need, so I don't have room for a third partition to send the
keystrokes from.

We're gonna go to a 386 and solve that problem later this month,
I hope.

DE>An alternate method - one that would keep you from "EXIT"ing out
DE>of any of the procs (though KILL and <CTRL><ALT><DEL> would still
DE>work) - would be to rename autoexec.bat and use the /P option for
DE>command.

I actually tried that, but didn't pursue it to the point of
installing it that way.  I may try that the next time I'm
fooling around.

--Tim Farley

Date: 06-04-90 (20:06)              Number: 467 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RON HOSSACK                     Read: (N/A)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I had requested info concerning this product about a month ago and
havn't seen anything come by the US Snail......would you plese check
and see if the brochures were mailed to me.....

Solid Rock BBS   [phone]   19200 - 1200  HST

Ron Hossack
3245Abbotsford
Riverside, CA  92503

PCRelay:LATENITE -> INTELEC (tm) Network, Freeport, NY
4.10ß14             The Late Show! Riverside, CA 714-359-5624 HST

Date: 06-03-90 (14:43)              Number: 468 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: ANDRE MANN                      Read: HAS REPLIES
Subj: IS IT WORTH IT?               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hi,

        I just downloaded Omniview and before I spend a few hours
cursing, I would like to know if it's worth the trouble of running it on
a 12Mhz. AT with a Meg. of RAM...

        If so, what pointers would you guys and gals give me to have a
go at it in the right direction?

Thanks,
┌─┐
│ │
├─┤ndré
└ └────


NET/Mail : Synapse BBS  Gatineau, QUE (819)-561-5268/6745 243-7179/0306

PCRelay:INTELEC -> Intelec (tm) Network, Freeport, NY
4.10ß14            Network Host: 516 867-4446/7 Hayes  -4448 HST

Date: 06-05-90 (06:36)              Number: 469 / 572 (Echo)
  To: ANDRE MANN                    Refer#: 468
From: RICK KUNZ                       Read: NO
Subj: IS IT WORTH IT?               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>        I just downloaded Omniview and before I spend a few hours
>cursing, I would like to know if it's worth the trouble of running it o
>a 12Mhz. AT with a Meg. of RAM...

 OMNIVIEW should not be posted for downloading anywhere, Andre. It is a
commercial program. I'm sure Dennis Edwards will be interested in
knowing from where it was downloaded, so the company can call and inform
the Sysop of that board.

Date: 06-06-90 (07:06)              Number: 470 / 572 (Ecto foreground...]
│DE>│DE>That's a feature, Tim. The logic behind it is as follows:
│
│Today a critical error occurred again...
│I am at the stage where I think we are perhaps having more
│fundamental hardware problems on this machine---this time it was
│a "Sector not found" error...
│This partition that keeps invoking the critical error handler is
│managed by Disk Manager.  Is there anything special we should be
│doing to use DMDRVR.BIN with OmniView?

Nothing special to do with Disk Manager - we used that on a machine here for
a while. We took it off because it became convenient to partition the drive
with DOS. We didn't have any problems when it was on, though.

│I'll see if I can fool around with FATAL when I have some time,
│and come back if I have further questions.  Thanks for the tips.

Good luck. I'm anxious to see what you come up with.

│I called you folks about getting the OAPI kit mailed to me,
│haven't seen anything in the mail just yet, though.

I'll get it to you if it hasn't been sent already.
Thanks for your patience.
---
 ■ EZ 1.22 ■

Date: 06-06-90 (10:48)              Number: 473 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 463
From: DENNIS EDWARDS                  Read: 06-07-90 (07:16)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Tim & Dennis:
│    Thank you very much for your replies  about  my  PCBoard
│problems.  The  batch  files and explanations should help me
│out alot.  I'll let you know what happens.

Glad you found my input useful. Good luck and let me know if you run into a
bind.

Take care.
---
 ■ EZ 1.22 ■

Date: 06-06-90 (13:00)              Number: 475 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: MIKE STROCK                     Read: HAS REPLIES
Subj: BLEED THROUGH WITH OV 4.1     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Howdy!  I finally got PCBoard running Two  nodes  on  an  XT
using  Omniview  4.10,  thanks  to an immense amount of help
from Tim Farley,  Dennis  Edwards,  and  Rick  Kunz.  Thanks
Guys!  My  only  question  now  is,  is there anyway to stop
bleed through when logged in locally?  If  anybody  has  any
ideas, I'm all ears.

    Mike Strock
    ButtonNet PCBoard
    206-454-7875 300/1200/2400 24hrs a day, 365 days a year
---
 ■ EZ 1.27 ■ Land of PC File 5.0

Date: 06-06-90 (15:00)              Number: 476 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 475
From: RICK KUNZ                       Read: 06-07-90 (07:16)
Subj: BLEED THROUGH WITH OV 4.1     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Guys!  My  only  question  now  is,  is there anyway to stop
>bleed through when logged in locally?  If  anybody  has  any
>ideas, I'm all ears.

 I haven't checked, Mike, but if Sunny Hill provides a modified ANSI.SYS
driver which is optimized to stop bleedthrough, you might try replacing
your standard ANSI driver. You really don't need ANSI.SYS for PCBoard,
anyway, as it uses its own routines for graphics anyway. Good luck!

Date: 06-06-90 (13:24)              Number: 477 / 572 (Echo)
  To: RON HOSSACK                   Refer#: NONE
From: DAVID CHRISTENSEN               Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RH>I had requested info concerning this product about a month ago and
RH>havn't seen anything come by the US Snail......would you plese check
RH>and see if the brochures were mailed to me.....

 Ditto, David Christensen
        332 First Avenue
        Bayport, NY 11705-1304  Thanks!

 Saved Jun 05, 1990, 2:10pm

  EMail 0318α From Bayport, Long Island NY - Relay-> SYSCOM R/O16677
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 06-07-90 (06:26)              Number: 478 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 465
From: DENNIS EDWARDS                  Read: 06-14-90 (17:29)
Subj: OMNIVIEW using HMA            Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│TF>Speaking of which, is there any thought that there might be a
│TF>future version of OMNIVIEW that *can* use the "High Memory Area"
│Barring a version of OV that could "live" up there, it still
│would be nice if it could make use of that memory---perhaps as
│scratch space.  Or it could allocate TopView "shadow" screens up
│there.  Or anyone of a number of things that take real RAM or EMS
│right now.

Point taken.
---
 ■ EZ 1.22 ■

Date: 06-07-90 (06:26)              Number: 479 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 466
From: DENNIS EDWARDS                  Read: 06-14-90 (17:29)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>You could avoid using exit commands by loading COMMAND in
│DE>resident mode (without the /C option) and then using SENDKEYS to
│DE>"type in" the initial commands in the new partition
│
│Neat trick---I'll have to look at possibly using that.  My main
│problem is I barely have enough RAM to run the two partitions I
│need, so I don't have room for a third partition to send the
│keystrokes from.

You could still do it - it would just take an extra batch file:

-- set %node% to 2.
-- start up OV with a .BAT file (running in a "node sized" proc) that loads
   proc 2 and sends it the keystrokes to start up a common batch file, then
   dies.
-- proc 2 tests to see if %node% is set to 2. If it is it waits for
   proc one to die, spawns the real node 1, "sets" node 1's %node% variable
   to 1, then sends it the keystrokes to start up the common batch file.
-- when the common batch file starts up in node 1, it checks %node% and,
   finding it to be '1' just skips down to the "start up the node"
   instructions.

│We're gonna go to a 386 and solve that problem later this month,
│I hope.

For the most part - those boxes make life much simpler.
---
 ■ EZ 1.22 ■

Date: 06-07-90 (06:26)              Number: 480 / 572 (Echo)
  To: ANDRE MANN                    Refer#: 468
From: DENNIS EDWARDS                  Read: NO
Subj: IS IT WORTH IT?               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│        I just downloaded Omniview and before I spend a few hours
│cursing, I would like to know if it's worth the trouble of running it on
│a 12Mhz. AT with a Meg. of RAM...
│
│        If so, what pointers would you guys and gals give me to have a
│go at it in the right direction?

Andre,

I have to say that OMNIVIEW is a commercial product and the BBS network is
not it's intended means of distribution. I realize that you did not have
knowledge of this. However, I would very much like a copy of the archive you
downloaded and the number of the board you got it from - as well as any
history you may have about the archive's distribution. We simply want to
limit the distribution of this pirate copy and the damage that it may be
doing to our livelihood. Please give either Ruth Yingst (President) or myself
a voice call at [phone]. We would be grateful.

With that out of the way... There are a couple of things that you can do to
minimise the hassle involved in getting OMNIVIEW up and running - or deciding
if you want to. First I would mention an "expert system" I wrote which is
designed to take a look around on the system it is running on and make some
(reasonably sound) guesses about what kind of performance you can get from
OMNIVIEW with your box. The second archive is a collection of application
notes that discuss various aspects of OMNIVIEW's operation.

Both of these are available on Rick Kunz' Poverty Rock BBS in Seattle - (206)
367-2596 - and have been distributed to a number of boards on the SmartNet
and INTELLEC networks. On Rick's board these will be found in the OMNIVIEW
directory as CONCUREn.ZIP and OVAPNn.ZIP, respectively (where 'n' is the
version number of the archive). Poverty Rock is the home board for this
conference and will always have the latest updates.

Because of the reader message limit, I am sending you a second message which
is the stock answer to the "what can I do with OMNIVIEW and a '286" question.
You also might want to set your message pointer for this conference back by
about 20 or so since Tim Farley posted some interesting batch files that he
uses to run his dual node BBS under OMNIVIEW on a '286.

If none of these answer specific questions you may have, please let me know
and I'll try to help. I look forward to hearing from you soon.

Thanks,

Dennis Edwards
Software Engineer

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

[phone]
---
 ■ EZ 1.22 ■

Date: 06-07-90 (06:26)              Number: 481 / 572 (Echo)
  To: ANDRE MANN                    Refer#: 468
From: DENNIS EDWARDS                  Read: NO
Subj: IS IT WORTH IT?               Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│ I would like to know if it's worth the trouble of running it on
│a 12Mhz. AT with a Meg. of RAM...

I assume that the initial Meg is 640K conventional, 384K extended on a '286
momboard. Probably the best use for extended memory, at least from OV's
perspective, is as a RAM disk. You can set the SWAP environment variable to
point to that drive and this will increase swapping speed. Since OV swaps on
a process by process basis, the resulting drive must be big enough to hold
all your swappable processes simultaneously: If you have three 300k swappable
processes and a 200k nonswappable process then you must have about 1M (300K *
3) reserved for the SWAP drive.

With your box, OMNIVIEW (and DESQview, etc.) will multitask only those
programs that can simultaneously fit in conventional memory (CONCURE can tell
you how much will be RAM will be left after running OMNIVIEW). Anything else
will be swapped to disk (if you let it) to make way for new programs. The
programs "on disk" won't run.

There on two kinds of concurrency supported by OMNIVIEW. Normal concurrency
is where a program is scheduled (on a preemptive, time sliced basis) whenever
its turn comes up: When this scheduling event occures depends on its priority
and quanta relative to the other current processes in the system. There are
16 priority queues (which can each hold ten processes) and each process may
have a quanta of 1-127 clock ticks. Scheduling events are considered on clock
tick. Omniview always trys to run a process with a higher priority if one is
available, if not, it will wait until the current process' quanta is expired
and then run the next highest priority process. A process that is waiting for
a system resource (such as a user's keystroke) will not be scheduled.

Interrupt concurrency is driven by hardware interrupts. On anything less than
a '386 system, interrupt driven processes must be nonswappable: That is,
fixed in the DOS Transient Program Area (TPA) - the room DOS has to run
normal programs, usually 640K. The last OV process to revector an IRQ is
given control of the CPU when that IRQ is generated. If no process has
revectored that IRQ it is passed on to the interrupt handler installed prior
to OV. With a '386 or later system and an appropriate memory manager
(currently only 386^MAX) these processes may run from EMS, provided they are
the last process to revecter a particular IRQ.

While on anything less than a '386 (with an appropriate memory manager)
interrupt driven processes can't run out of EMS. On these earlier systems,
EMS can still be useful, however. The things you can do with EMS depend on
the LIM hardware, the design of your motherboard, the type of video
adapter(s) in the system and the software you plan to run. With LIM 3.2 EMS
hardware (even with a LIM 4.0 driver), you can only do two things:

1) Swap processes using the EMS as a sort of fast RAM drive that will
overflow to some logical drive when it fills up.

2) Load the OMNIVIEW menu into the page frame. This takes 64K of EMS but only
9K out of the TPA. A few programs, such as Microsoft Windows and the
Lantastic network, do not like programs that run out of the page frame so
this may, or may not, be useful to you.

With LIM 4.0 EMS hardware and a LIM 4.0 driver you can also do the following:

1) Load OMNIVIEW into a 48K contiguous EMS (or XMS) block located somewhere
between the top of the video adapter (BIOS) and the bottom of the system ROM
BIOS. This is accomplished by configuring your memory manager to
perform/allow this allocation and then running OMNIHIGH.

2) "Topfill" from the top of conventional memory to the bottom of the first
video adapter's regen buffer. When an EGA/VGA (and some other "non-standard"
high resolution displays) the regen buffer starts at the 640K boundary and
this can't be done reliably. With an MDA or Hercules adapter you get an extra
64K (704K of DOS) and with a CGA you get an extra 96K (736K of DOS).

3) "Backfill" the motherboard. This requires that you remove conventional
memory from the motherboard and configure your memory manager to map EMS into
this vacant address space. The amount of conventional memory that you can
remove depends on the design of your system hardware and the assumptions made
by the BIOS Pre-Operation Startup Tests (POST). Consult you hardware
documentation for details.

Once you have accomplished the backfill, the size of the EMS block mapped
into the DOS TPA (Kbytes of backfill + Kbytes of topfill), will determine the
size of the largest swappable program for which normal concurrency is
supported. The number of normally concurrent processes you can have running
at one time will depend on you're free EMS. With 2M of EMS, an MDA (64K
topfill), 256K on the momboard (384K backfill), 580K free after AUTOEXEC is
run (644K free w/ topfill), and a 250K communications program running in
partition one, you would have:
        644K    total TPA
      -  12K    typical TPA impact from loading OMNIVIEW in high memory
      - 250K    space taken up by the non-swappable .COM program
      -------
        382K    remaining for normally concurrent processes
On all systems, EMS is community property. OMNIVIEW uses it to store/run
processes and these processses may use it to store data, overlays, etc. You
can limit the amount of EMS a process can use. If only one process were
allowed to use EMS and that use was limited to 500K, then you could run 3
( 1 + ((2048K - 64K - 48K -448K -500K) / 382K) ) normally concurrent
processes and have about 200K of EMS remaining.
---
 ■ EZ 1.22 ■

Date: 06-09-90 (06:37)              Number: 482 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 475
From: DENNIS EDWARDS                  Read: 06-11-90 (06:39)
Subj: BLEED THROUGH WITH OV 4.1     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Howdy!  I finally got PCBoard running Two  nodes  on  an  XT

Good deal, Mike!

│My only question now is, is there anyway to stop
│bleed through when logged in locally? If anybody has any
│ideas, I'm all ears.

Depends on what it is that's bleeding through.

What your seeing is, of course, the result of the background process poking
data into the regen buffer which is "owned" by the foreground program. You
have 3 options:

    1) Upgrade to a 386.
    2) Turn off the program in background.
    3) Convince the background programs not to write directly to the screen.

PCB (and some others) will turn off direct screen writes to the physical
screen if they detect a positive response from either a TopView or DESQview
"get virtual screen" call. OMNIVIEW implements both of these system calls.
The DESQview call is always emulated. To turn on the TopView emulation in
OMNIVIEW either set TopView Emulation to "Yes" in the menu or add a "/T"
parameter to the OMNIVIEW/OMNIHIGH/SPAWN/OPEN command lines when you create
the proc. The /t switch allocates a device for the given partition that
emulates certain TopView functions.

Give /t a try. If you end up with a screen that "jerks", you can use the
VSCRNOFF utility to reset video updates to "auto" for its partition.
---
 ■ EZ 1.22 ■

Date: 06-09-90 (06:37)              Number: 483 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 477
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│RH>I had requested info concerning this product about a month ago and

Sorry, I'll check on it.
---
 ■ EZ 1.22 ■

Date: 06-10-90 (11:15)              Number: 484 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DAVID CHRISTENSEN               Read: 06-11-90 (07:07)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│RH>I had requested info concerning this product about a month ago and

DE>Sorry, I'll check on it.

 Thank You, Dennis.

 Saved Jun 09, 1990, 10:31pm

  EMail 0318α From Bayport, Long Island NY - Relay-> SYSCOM R/O16677
---
 ■ RNet 1.04R: Sound Of Music BBS + Smartnet HUB

Date: 06-10-90 (22:13)              Number: 487 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DAVE CALMER                     Read: 06-14-90 (14:38)
Subj: Information                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Sorry to inform you, I to am one of the forgotten that requested info on
Omniview.

                       The DANGER ZONE!! BBS
                       PO Box 6154
                       Rock Island, Il. 61201

PCRelay:DANGRZN -> Intelec (tm) North Central SuperRegional
4.10ß14            The Danger Zone!! >>><<< [phone]

Date: 06-15-90 (14:24)              Number: 488 / 572 (Echo)
  To: DAVE CALMER                   Refer#: 487
From: DENNIS EDWARDS                  Read: NO
Subj: Information                   Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Sorry to inform you, I to am one of the forgotten that requested info on
│Omniview.

Don't know what to say guys...
We are trying again. Thanks for your patience.
---
 ■ EZ 1.22 ■

Date: 06-15-90 (15:34)              Number: 489 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 479
From: TIM FARLEY                      Read: 06-18-90 (08:51)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>You could still do it - it would just take an extra batch file:

Yeah, neat idea---have one start the other, and vice versa.

One advantage to your scheme is it probably could be adapted such
that one node could automagically restart the other node in the
event of a crash.   Each node could check and see if the other
one is running ok, and if not, spawn a new copy of it.

Hmmmmm.....will have to look into that after I get finished
shuffling hardware and furniture around here.

--Tim Farley

Date: 06-15-90 (15:34)              Number: 490 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 472
From: TIM FARLEY                      Read: 06-18-90 (08:51)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

TF>This partition that keeps invoking the critical error handler is
TF>managed by Disk Manager.  Is there anything special we should be
TF>doing to use DMDRVR.BIN with OmniView?

DE>Nothing special to do with Disk Manager

Good to know.

Update:  since the last exciting episode of "Tim Bothers Dennis",
Tim decided to run SpinRite II on the offending drive.  It turns
out that the C: partition, and the D: partition (which were both
on the same physical drive) were actually formatted at two
different interleave values!

SpinRite fixed this, and the other problems too, and now
everything runs smoothly.  No more INT 24 occurances.


Question:  SpinRite does an "analysis" of an optimum interleave
based on the speed of the processor, etc.  I let it take its
suggestion action, but later it occurred to me that the overhead
incurred by OmniView being in the system might make SpinRite's
interleave settings too optimistic.   (As per the suggestions in
the SpinRite manual, I did NOT run SpinRite inside OmniView).

Or does the fact that OmniView does not do task switches while
inside a DOS call make this moot?  In other words, since DOS
isn't going to get interrupted while reading the disk, is it true
that the OmniView overhead will not affect what would make a good
interleave setting?


To further confuse you (got to make you earn your money, heh) we
have Super PC-Kwik loaded, and I have it set to use a "track
buffer" of one full track in length.  I assume that would factor
in, since PC-Kwik will preload an entire track at a shot, thereby
maximizing data throughput at current interleave, etc.

--Tim Farley

Date: 06-23-90 (08:27)              Number: 491 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 489
From: DENNIS EDWARDS                  Read: 06-25-90 (18:53)
Subj: OMNIVIEW AND PCBOARD 14.2     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>You could still do it - it would just take an extra batch file:
│Yeah, neat idea---have one start the other, and vice versa.
│
│One advantage to your scheme is it probably could be adapted such
│that one node could automagically restart the other node in the
│event of a crash.   Each node could check and see if the other
│one is running ok, and if not, spawn a new copy of it.

Yup. Watchdog PCBs. Whataconcept.
---
 ■ EZ 1.22 ■

Date: 06-23-90 (08:27)              Number: 492 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 490
From: DENNIS EDWARDS                  Read: 06-25-90 (18:53)
Subj: INT 24 lockup problem         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│TF>This partition that keeps invoking the critical error handler is
│TF>managed by Disk Manager.  Is there anything special we should be
│...
│SpinRite fixed this, and the other problems too, and now
│everything runs smoothly.  No more INT 24 occurances.

THATS good. Gibson done himself proud with SpinRite, fer sure.
(And don't sweat the questions - swat I'm here for.)

│Question:  SpinRite does an "analysis" of an optimum interleave
│based on the speed of the processor, etc.  I let it take its
│suggestion action, but later it occurred to me that the overhead
│incurred by OmniView being in the system might make SpinRite's
│interleave settings too optimistic.   (As per the suggestions in
│the SpinRite manual, I did NOT run SpinRite inside OmniView).
│
│Or does the fact that OmniView does not do task switches while
│inside a DOS call make this moot?  In other words, since DOS
│isn't going to get interrupted while reading the disk, is it true
│that the OmniView overhead will not affect what would make a good
│interleave setting?
│
│To further confuse you (got to make you earn your money, heh) we
│have Super PC-Kwik loaded, and I have it set to use a "track
│buffer" of one full track in length.  I assume that would factor
│in, since PC-Kwik will preload an entire track at a shot, thereby
│maximizing data throughput at current interleave, etc.

I have, to this point, been fairly successful in avoiding learning how the
disk hardware works. But I do know this - when you want to get data from some
archival storage media, DOS spends a lot of time hanging out waiting for the
hardware to process the request. The process of encoding the magnetic (or
optical) impluses on this media into processor digestible chunks of digital
impulses is a hardware task. Servos rotate at a more or less fixed rate, head
and head gap reluctance are independent of processor clock rate and opamp
slew is independent of the thread context that may be functioning within the
microprocessor hardware coincidently. Additionaly, these considerations are
not directly affectable by software.

I find it helpful to look at what SpinRite's interleave adjustment does by
looking at the situation using the analogy of a lazy susan and a robot arm
where the lazy susan rotates at a fixed rate and the robot arm has a fixed
response time. I imange the task of the robot arm is to pick a bunch of
bottles off the lazy susan and put them in a shipping case. The bottles are
numbered sequentially and must be put in the box in numerical order. This
means that when it is ready to pick up the next bottle off the lazy susan,
the one it needs may be on the other side from where, or (worse yet) just
gone past where, the robot can reach it. When this is True, the robot must
wait for the bottle to spin 'round where it is range before it can pick it
up. This waiting is a waste of time.

What SpinRite does is modify the bottle delivery system so that a human
watching the numbered bottles go by on the lazy susan would see them as out
of sequence. The robot however - because it only cares about putting the
bottles in a box - would always find the correct bottle under its claw when
it was ready to pick up another one. Reordering the sequence of the bottles
on the lazy susan is the only way to accomplish this - short of buying a new
robot. Increasing expenditures on faster delivery trucks or redesigning the
shipping boxes will not overcome the delay the robot puts in the system if it
finds the bottles out of sequence relative to its own task. (Though putting
the shipping boxes on seperate lazy susans could improve the delivery
system efficiency, it would do so at the cost of a very complicated truck
loading task).

That is why, by increasing the interleave on my old PC from 3:1 to 5:1, I
gained a 170% increase in the disk response time - because the hard disk data
bottling robot, when it reached to the lazy susan, found the bottles under
its claw more often than it did before. Since PC-KWIK still has to depend on
the robot to get the bottled data into its cache, you will suffer the same
performance burden as if it weren't there at all whenever you access data
that isn't resident within the cache. What a cache _can_ do for you -
particularly one with "look ahead"- is save up stuff that the robot has
already put in boxes into a sort of surge tank so that when it comes time for
you to ask for data you are impaired only by the time limitations of the
digital circuitry rather than the electro/optical-mechanical
hysterisis/inertia of the actual disk mechanism.

You sorta have the cart before the horse when you perceive that OV impacts on
disk performance. The time it takes for data to get on the sytem bus is cast,
if not in concrete, at least in silicon, iron and copper. Since OMNIVIEW must
suspend any context execution until a DOS call returns, and since the
electro/optical-mechanical hysterises/inertia is by far the biggest bottle
neck in the archival data delivery system - anything you can do to reduce
that time will increase the overall performance of the system as a whole and
this includes the multitasking environment.

In short, the benefits of interleave adjustment are real and fundamental. I
haven't bothered to verify Gibson's performance claims so I don't know if
they are absolutely correct (whatever that means) but I do know from
experience that SpinRite can perceptibly improve your system efficiency.
---
 ■ EZ 1.22 ■

Date: 06-23-90 (10:58)              Number: 493 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 492
From: RICK KUNZ                       Read: 06-27-90 (06:24)
Subj: "Optimization"                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Excellent post on Optimization, Dennis. Mind if I copy that over to the
NEWUSERS conference? I think it elucidates the process quite well.

Date: 06-27-90 (19:15)              Number: 494 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 493
From: DENNIS EDWARDS                  Read: 06-27-90 (22:15)
Subj: "Optimization"                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Excellent post on Optimization, Dennis. Mind if I copy that over to the
│NEWUSERS conference? I think it elucidates the process quite well.

Uhhh, no, I guess not. But I don't remember what you're refering to
(sorry)...

---
 ■ EZ 1.30 ■

Date: 06-27-90 (22:16)              Number: 495 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 494
From: RICK KUNZ                       Read: 06-29-90 (09:51)
Subj: "Optimization"                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Uhhh, no, I guess not. But I don't remember what you're refering to

 The Int 24 post; actually it was about interleave optimization.

Date: 06-29-90 (12:55)              Number: 496 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 495
From: DENNIS EDWARDS                  Read: 06-29-90 (19:13)
Subj: "Optimization"                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>Uhhh, no, I guess not. But I don't remember what you're refering to
│ The Int 24 post; actually it was about interleave optimization.

Oh. Sure, use it. Glad you found the analogy useful.
---
 ■ EZ 1.30 ■

Date: 07-13-90 (06:21)              Number: 497 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RON JOUBERT                     Read: HAS REPLIES
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Itty Bitty BBS of Spfld MA is now echoing this conference.
---
 ■ RNet 1.04U: ■INTELEC >Itty Bitty BBS ■ Springfield ■ MA ■ [phone]

PCRelay:INTELEC -> #402 Intelec (tm) Network, Freeport, NY
4.10ß15            PCRelay/Rnet/Qnet/NetMail and the best users!

Date: 07-14-90 (23:36)              Number: 498 / 572 (Echo)
  To: RON JOUBERT                   Refer#: 497
From: RICK KUNZ                       Read: NO
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Itty Bitty BBS of Spfld MA is now echoing this conference.

 Welcome, Ron! Glad to see your board in the OMNIVIEW conference; we
hope your users of the program enjoy it!

Date: 07-18-90 (15:21)              Number: 499 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 498
From: JEFFERY FOY                     Read: 07-18-90 (16:36)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RK>>Itty Bitty BBS of Spfld MA is now echoing this conference.
RK>
RK> Welcome, Ron! Glad to see your board in the OMNIVIEW conference; we
RK>hope your users of the program enjoy it!

Er, excuse the ignorance here, Rick, but what IS this OMNIVIEW? Is
it another of the TOPVIEW/DESQVIEW ilk?

Jeff
---
 ■ EZ 1.30 ■

Date: 07-18-90 (16:36)              Number: 500 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 499
From: RICK KUNZ                       Read: 07-19-90 (12:18)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Er, excuse the ignorance here, Rick, but what IS this OMNIVIEW? Is
>it another of the TOPVIEW/DESQVIEW ilk?

 OMNIVIEW is a multitasker program, and it developed out of
Taskview. Dennis Edwards, mild-mannered Ace Programmer for Sunny Hill
Software (here in Everett, Wash.!) will no doubt upload you a more
complete response. It's easily command-driven and works with LANs pretty
well. Good stuff!

Date: 07-19-90 (14:30)              Number: 501 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 500
From: JEFFERY FOY                     Read: 07-19-90 (14:53)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RK> OMNIVIEW is a multitasker program, and it developed out of
RK>Taskview.

Oh, didn't know that. Always wondered what happened to Taskview.

RK>Dennis Edwards, mild-mannered Ace Programmer for Sunny Hill
RK>Software (here in Everett, Wash.!) will no doubt upload you a more
RK>complete response.

Dennis, if you see this, feel free. I am quite interested.

RK>It's easily command-driven and works with LANs pretty well.
RK>Good stuff!

Now for the $64.00 question - will it run in conjunction with a
BBS?

Jeff
---
 ■ EZ 1.30 ■

Date: 07-23-90 (06:31)              Number: 502 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 501
From: MIKE STROCK                     Read: 07-23-90 (11:52)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Jeff,
  You can definitely run a bbs under Omniview.  I'm running a two
  node bbs (PCBoard 14.5/E3 (Beta) under Omniview on an XT.  Took
  quite a while to get it set up correctly (with a lot of help
  from Tim Farley (SemWare BBS) and Rick (Poverty Rock), but
  it is working really well.  Give it a call and leave me a
  message if you have any questions I can answer.

     Mike
     ButtonNet PCBoard [phone] 24hrs 300/1200/2400 baud.
---
 ■ EZ 1.29 #1078 ■ Castration: Circumcision beyond your control.

Date: 07-23-90 (15:38)              Number: 503 / 572 (Echo)
  To: MIKE STROCK                   Refer#: 502
From: JEFFERY FOY                     Read: 07-24-90 (06:45)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

MS>Jeff,
MS>  You can definitely run a bbs under Omniview.

Just what I needed to hear! :)

MS>  I'm running a two
MS>  node bbs (PCBoard 14.5/E3 (Beta) under Omniview on an XT.

On an XT? Neat. So far you're batting 1000 with me. :)

MS>  Took
MS>  quite a while to get it set up correctly (with a lot of help
MS>  from Tim Farley (SemWare BBS) and Rick (Poverty Rock), but
MS>  it is working really well.

SHHH! Don't let Rick hear you say that. It'll blow his image of
being humble. :)

MS>  Give it a call and leave me a
MS>  message if you have any questions I can answer.

Thanks, Mike, I'll do that.

MS> ■ EZ 1.29 #1078 ■ Castration: Circumcision beyond your control.

A little of the sides and off the top, eh?  ;)  (hehehehehehe)

Jeff
---
 ■ EZ 1.30 ■

Date: 07-23-90 (02:56)              Number: 504 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: DAVID CHRISTENSEN               Read: 07-27-90 (11:05)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE╢Date: 04-21-90 (10:03)           Number: 130       Intelec Business Netwo
DE╢  To: DAVID CHRISTENSEN          Refer#: NONE
DE╢From: DENNIS EDWARDS               Read: NO
DE╢Subj: OMNIVIEW                     Conf: (3) OmniView
DE╢│ Mind sending me some info? (and demo if one exists?), As well do you
DE╢Will send a brochure, come the workweek. No demo. We offer a 35% sysop
DE╢discount but none for students per se.

 Well its been 3 months, no brochure.....if you want to try again:

 332 First Avenue
 Bayport, NY 11705-1304


■ dMail 0·1 ■ Backup not found: (a)bort (r)etry (p)anic

PCRelay:INTELEC -> #402 Intelec (tm) Network, Freeport, NY
4.10ß15            PCRelay/Rnet/Qnet/NetMail and the best users!

Date: 07-24-90 (10:49)              Number: 505 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: PETER WILLIAMS                  Read: HAS REPLIES
Subj: HELLO                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)



CCSBoard, The BBS of Creative Computer Solutions, In Emerson, NJ
is proud to be carrying this conference.
---
 ■ RNet 1.04U: CCSBoard - Emerson NJ

PCRelay:INTELEC -> #402 Intelec (tm) Network, Freeport, NY
4.10ß15            PCRelay/Rnet/Qnet/NetMail and the best users!

Date: 07-24-90 (23:39)              Number: 506 / 572 (Echo)
  To: PETER WILLIAMS                Refer#: 505
From: RICK KUNZ                       Read: NO
Subj: HELLO                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>CCSBoard, The BBS of Creative Computer Solutions, In Emerson, NJ
>is proud to be carrying this conference.

 Welcome, Peter! Glad to have your board carrying OMNIVIEW support!
Omniview is a great multitasker program and the folks at Sunny Hill
Software have their premiere techie, Dennis Edwards, as
support-person-guru here. Omniview even offers a deal for Sysops --
which is always appreciated by us beleaguered Sysops!

Date: 07-26-90 (07:00)              Number: 507 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: TOM OPPENHEIMER                 Read: 07-27-90 (11:05)
Subj: SETTING UP A WILDCAT BBS      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I am in the process of upgrading a single line Wildcat bbs to a
multiline board (2 lines) and would appreciate any help you can give in
setting up OMNIVIEW for this. Also if you know of any Wildcat boards
that are setup this way, I'd like to get together with them for any help
they can give.
For the record, the computer is an AT clone with 1100k or EXTENDED
memory (in addition to the 640K base). No EXPANDED memory.
Thanks!

Date: 07-27-90 (18:57)              Number: 508 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 501
From: TIM FARLEY                      Read: 07-27-90 (20:01)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

JF>Now for the $64.00 question - will it run in conjunction with a
JF>BBS?

We also run a 2-node PCBoard BBS here in Atlanta under OmniView.

--Tim Farley

Date: 07-27-90 (22:51)              Number: 509 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 508
From: JEFFERY FOY                     Read: 08-02-90 (14:55)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

TF>JF>Now for the $64.00 question - will it run in conjunction with a
TF>JF>BBS?
TF>
TF>We also run a 2-node PCBoard BBS here in Atlanta under OmniView.

And we thank you for your support! :)

Jeff
---
 ■ EZ 1.30 ■

Date: 07-27-90 (13:32)              Number: 510 / 572 (Echo)
  To: MIKE STROCK                   Refer#: NONE
From: RANDY NOSEWORTHY                Read: 07-28-90 (09:18)
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Jeff, I've got some qestions, how fast is your XT, and also, is there any
slowdown of the BBS due to the fact that it is running two nodes. Also
how much memory are you useing ect.... I've got an IBM mother board on
my XT with a Vic 20 chip, so I'm running at about 5.33... ( Whoa! what
speed! ) I only have 512k and the BBS that I run will want 250k and
then there are the doors... I can more than likely get away with about
310-320k for one node... I am just full of questions... I've looked at
Double Dos, and it is quite Chunky, and I've also seen Desqview, but I
don't think that Desqview will run on an XT.... I've thought about
going to one meg, and use of a Ram drive to speed things up, but I
still don't know what type of multitasker would work right, if I were
to go multi-node... Umm.... That is all that I can think of at the
moment.... :)

    Randy

PCRelay:CALSTAR -> #436 INTELEC + msgs Copyright 1990 by author.

Date: 07-29-90 (08:28)              Number: 511 / 572 (Echo)
  To: RANDY NOSEWORTHY              Refer#: 510
From: MIKE STROCK                     Read: NO
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RN]Jeff, I've got some qestions, how fast is your XT, and also, is there any
RN]slowdown of the BBS due to the fact that it is running two nodes. Also
RN]how much memory are you useing ect.... I've got an IBM mother board on
RN]my XT with a Vic 20 chip, so I'm running at about 5.33... ( Whoa! what
RN]speed! ) I only have 512k and the BBS that I run will want 250k and
RN]then there are the doors... I can more than likely get away with about
RN]310-320k for one node... I am just full of questions... I've looked at
RN]Double Dos, and it is quite Chunky, and I've also seen Desqview, but I
RN]don't think that Desqview will run on an XT.... I've thought about
RN]going to one meg, and use of a Ram drive to speed things up, but I
RN]still don't know what type of multitasker would work right, if I were
RN]to go multi-node... Umm.... That is all that I can think of at the
RN]moment.... :)
Randy,
   I was the one that is running the bbs.  Anyway,  I'm running on an
   original IBM PC with an Mach 20 board to speed it up. Quite
   I'd much prefer running on a 386sx, but not for now.  I would
   suggest upgrading to at least 640k.  I'm running the two nodes
   under 640k, but I'm running an Overlay version of PCboard which
   does not take up as much memory as the previous non-overlay
   versions do.  Don't think doors will work under a multi-tasking
   environment with an XT, I can't get Prodoor working on our system
   due to memory problems.

    Hope this helps you out.
      Mike.
---
 ■ EZ 1.29 #1078 ■ PS/2 - Half a Computer! (or less)

Date: 07-30-90 (10:36)              Number: 512 / 572 (Echo)
  To: PETER WILLIAMS                Refer#: 505
From: DENNIS EDWARDS                  Read: NO
Subj: HELLO                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│CCSBoard, The BBS of Creative Computer Solutions, In Emerson, NJ
│is proud to be carrying this conference.

Welcome. Thanks for picking it up. Let me know if you have any questions I
might be able to answer.

Dennis Edwards
Omniview Conference Host
---
 ■ EZ 1.30 ■

Date: 07-30-90 (10:36)              Number: 513 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 499
From: DENNIS EDWARDS                  Read: 07-31-90 (12:50)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Er, excuse the ignorance here, Rick, but what IS this OMNIVIEW? Is
│it another of the TOPVIEW/DESQVIEW ilk?

Howdy. Thanks for your interest in OMNIVIEW. Here is a stock blurb, please let
me know if it doesn't answer your questions, OK?

OMNIVIEW Advertisement

OMNIVIEW (formerly TASKVIEW) is a preemptive multitasker for DOS
programs; this differentiates it from Microsoft Windows, Software
Carousel and others which do not provide true multitasking. You
CAN achieve true multitasking with Microsoft windows by running
multiple Windows '286 applications inside of OMNIVEW.

Unlike Quartedeck's DESQView, each OMNIVIEW process is a full
screen application - this makes OMNIVIEW both smaller and faster;
A very important consideration when running concurrent real time
applications (such as high speed communication programs or
industrial control systems) or when relying on memory hungry
device drivers and TSRs. Any TopView/DESQView aware application
will run as expected.

In contrast to VM/386, OMNIVIEW does not utilize (nor impose the
overhead of) the multiple '386 virtual 8086 modes. Each process
operates in a single virtual 8086 address space. All device
drivers and TSRs loaded before OMNIVIEW are global to all
processes.

The increasingly popular "dos extenders" may be fully utilized
inside any OMNIVIEW partion, allowing multiple concurrent
multi-megabyte applications.  While OMNIVIEW is compatible with
Quarterdeck's QEMM and other virtual control programs, we
recommend Qualitas' 386^MAX ($49.95) to get the maximum benefit
of OMNIVIEW on '386 systems; the professional version of this
program ($100) will also load device drivers into high memory,
maximizing the space available to run other programs.

SysOps quilify for a 35% discount off OMNIVIEW's $79.95 retail
price.

OMNIVIEW's features include:

-- As many as ten concurrently operating programs on a single
   machine.
-- Runs on all PC/AT/PS/2 machiness from 8088 to 80486 based
   systems.
-- True multitasking with dynamically configurable time slice
   duration (127 levels) and relative process priorities (15
   levels).
-- Utilizes LIM 3.2, 4.0 and EEMS memory.
-- TSR's loaded before OMNIVIEW can be accessed by all processes.
-- TSR's loaded inside partitions act just as any other program,
   to remove them just kill the partition.
-- Supports all standard video adapters in all modes.
-- Loads in as little as 9K of conventional memory.
-- INCREASES memory available to run DOS applications by over 80K
   on some systems.
-- Keyboard macros and the ability to "cut and paste" among
   applications.
-- Easy to use menu interface.
-- Command line interface with a powerful collection of utility
   programs allows experienced users maximum flexibility.
-- Free technical support and much more.

The OMNIVIEW Application Programmer's Interface (OAPI), available
for the asking, has supported C, ASM and Turbo Pascal programmers
since 1986.  All OAPI applications have the ability to:

-- Create and eliminate sibling processes.
-- Suspend, activate and control sibling processes.
-- Send keystrokes to programs running in other partitions.
-- Send and receive various message objects.
-- Perform time sequenced, background events.
-- Establish shared data areas.
-- Create "invisible" customized user interfaces for integrated
   multitasking applications.
-- and much more.


Mailing Address:

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278

FAX:  [phone] - Be sure to SPECIFICALLY ADDRESS all FAX
      messages to Sunny Hill Software.

VOICE:  [phone] - USA and Canada (including WA state).

BBS:    [phone]: Poverty Rock BBS

This is a private board run by Rick Kunz. Rick has kindly
provided space on the board for OMNIVIEW related files
and this board serves as the OMNIVIEW support conference.
     * * * C O N T I N U E D   T O   N E X T   M E S S A G E * * *
---
 ■ EZ 1.30 ■

Date: 07-30-90 (10:36)              Number: 514 / 572 (Echo)
  To: DAVID CHRISTENSEN             Refer#: 504
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE╢Date: 04-21-90 (10:03)           Number: 130       Intelec Business Netwo
│DE╢  To: DAVID CHRISTENSEN          Refer#: NONE
│ 332 First Avenue
│ Bayport, NY 11705-1304

Trying...

The advertisement I just posted to Jeff contains essentially the same thing
you would get in the written brochure. Anything, specifically, that you would
like to know now?

---
 ■ EZ 1.30 ■

Date: 07-30-90 (10:36)              Number: 515 / 572 (Echo)
  To: TOM OPPENHEIMER               Refer#: 507
From: DENNIS EDWARDS                  Read: 08-30-90 (09:08)
Subj: SETTING UP A WILDCAT BBS      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I am in the process of upgrading a single line Wildcat bbs to a
│multiline board (2 lines) and would appreciate any help you can give in
│setting up OMNIVIEW for this. Also if you know of any Wildcat boards
│that are setup this way, I'd like to get together with them for any help
│they can give.
│For the record, the computer is an AT clone with 1100k or EXTENDED
│memory (in addition to the 640K base). No EXPANDED memory.
│Thanks!

First off - you'll need to make both nodes non-swappable on your 286. This
means that they will both have to fit in memory on top of OMNIVIEW which takes
up about 50K. So you'll probably have about (580-50)/2 ≈ 250K-260K available
per node after COMMAND, the process tables, etc. are all loaded into memory.

The best way to max out your use of memory is to start up OV with a partition
of this size running COMMAND. Once that is up then you can run a batch file
that will start up the partition for node 2 two, start up both nodes and do
whatever housecleaning you need to do should one of them die. If you can, you
might want to look back about 20 or so messages here - Tim posted a set of
.BAT files that, while specific to PCB, could probably serve as a good
starting point for your project.

Unfortunately, I don't have any information specific to Wildcat BBSs or to
people who may be running that software. Other than keeping everything in
memory you'll also want to make sure that each node is using a separate I/O
port and IRQ. You may want to experiment with adding the '/T' switch to the
commands that open these partitions if you experience screen bleedthrough.
This switch turns on OMNIVIEW's TopView emulation and causes some programs to
recognise they are running under a multitasker that might not otherwise know.

I am posting a stock message for you in conjunction with this reply which
answers some common questions about OMNIVIEW running on a 286. If that doesn't
tell you anything of interest then please let me know what else you need and
I'll try to help.  Also, you may want to drop by Rick Kunz BBS [phone]
and take a look at the files in the OMNIVIEW directory. Of particular interest
may be the OMNIVIEW application notes and the Batch files that deal with
creating/managing DOS partitions. The latter also contains a text file
distilled from a multipart post that went along with those .BATs.

Good luck, and let me know what else you might need.
---
 ■ EZ 1.30 ■

Date: 07-30-90 (10:36)              Number: 516 / 572 (Echo)
  To: TOM OPPENHEIMER               Refer#: 507
From: DENNIS EDWARDS                  Read: 08-30-90 (09:08)
Subj: SETTING UP A WILDCAT BBS      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Another Stock Blurb: OMNIVIEW on a 286.

Probably the best use for extended memory, at least from OV's perspective, is
as a RAM disk. You can set the SWAP environment variable to point to that
drive and this will increase swapping speed. Since OV swaps on a process by
process basis, the resulting drive must be big enough to hold all your
swappable processes simultaneously: If you have three 300k swappable
processes and a 200k nonswappable process then you must have about 1M (300K *
3) reserved for the SWAP drive.

There on two kinds of concurrency supported by OMNIVIEW. Normal concurrency
is where a program is scheduled (on a preemptive, time sliced basis) whenever
its turn comes up: When this scheduling event occures depends on its priority
and quanta relative to the other current processes in the system. There are
16 priority queues (which can each hold ten processes) and each process may
have a quanta of 1-127 clock ticks. Scheduling events are considered on clock
tick. Omniview always trys to run a process with a higher priority if one is
available, if not, it will wait until the current process' quanta is expired
and then run the next highest priority process. A process that is waiting for
a system resource (such as a user's keystroke) will not be scheduled.

Interrupt concurrency is driven by hardware interrupts. On anything less than
a '386 system, interrupt driven processes must be nonswappable: That is,
fixed in the DOS Transient Program Area (TPA) - the room DOS has to run
normal programs, usually 640K. The last OV process to revector an IRQ is
given control of the CPU when that IRQ is generated. If no process has
revectored that IRQ it is passed on to the interrupt handler installed prior
to OV. With a '386 or later system and an appropriate memory manager
(currently only 386^MAX) these processes may run from EMS, provided they are
the last process to revecter a particular IRQ.

While on anything less than a '386 (with an appropriate memory manager)
interrupt driven processes can't run out of EMS. On these earlier systems,
EMS can still be useful, however. The things you can do with EMS depend on
the LIM hardware, the design of your motherboard, the type of video
adapter(s) in the system and the software you plan to run. With LIM 3.2 EMS
hardware (even with a LIM 4.0 driver), you can only do two things:

1) Swap processes using the EMS as a sort of fast RAM drive that will
overflow to some logical drive when it fills up. This is the single benefit
to be derived from software EMS emulators that work with extended memory: the
ability to overflow the EMS to a physical disk.

2) Load the OMNIVIEW menu into the page frame. This takes 64K of EMS but only
9K out of the TPA. A few programs, such as Microsoft Windows and the
Lantastic network, do not like programs that run out of the page frame so
this may, or may not, be useful to you.

With LIM 4.0 EMS hardware and a LIM 4.0 driver you can also do the following:

1) Load OMNIVIEW into a 48K contiguous EMS (or XMS) block located somewhere
between the top of the video adapter (BIOS) and the bottom of the system ROM
BIOS. This is accomplished by configuring your memory manager to
perform/allow this allocation and then running OMNIHIGH.

2) "Topfill" from the top of conventional memory to the bottom of the first
video adapter's regen buffer. When an EGA/VGA (and some other "non-standard"
high resolution displays) the regen buffer starts at the 640K boundary and
this can't be done reliably. With an MDA or Hercules adapter you get an extra
64K (704K of DOS) and with a CGA you get an extra 96K (736K of DOS).

3) "Backfill" the motherboard. This requires that you remove conventional
memory from the motherboard and configure your memory manager to map EMS into
this vacant address space. The amount of conventional memory that you can
remove depends on the design of your system hardware and the assumptions made
by the BIOS Pre-Operation Startup Tests (POST). Consult you hardware
documentation for details.

Once you have accomplished the backfill, the size of the EMS block mapped
into the DOS TPA (Kbytes of backfill + Kbytes of topfill), will determine the
size of the largest swappable program for which normal concurrency is
supported. The number of normally concurrent processes you can have running
at one time will depend on you're free EMS. With 2M of EMS, an MDA (64K
topfill), 256K on the momboard (384K backfill), 580K free after AUTOEXEC is
run (644K free w/ topfill), and a 250K communications program running in
partition one, you would have:
        644K    total TPA
      -  12K    typical TPA impact from loading OMNIVIEW in high memory
      - 250K    space taken up by the non-swappable .COM program
      -------
        382K    remaining for normally concurrent processes

On all systems, EMS is community property. OMNIVIEW uses it to store/run
processes and these processses may use it to store data, overlays, etc. You
can limit the amount of EMS a process can use. If only one process were
allowed to use EMS and that use was limited to 500K, then you could run 3
( 1 + ((2048K - 64K - 48K -448K -500K) / 382K) ) normally concurrent
processes and have about 200K of EMS remaining.







     * * * C O N T I N U E D   T O   N E X T   M E S S A G E * * *
---
 ■ EZ 1.30 ■

Date: 07-31-90 (18:16)              Number: 517 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 513
From: JEFFERY FOY                     Read: 08-01-90 (06:02)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>│Er, excuse the ignorance here, Rick, but what IS this OMNIVIEW? Is
DE>│it another of the TOPVIEW/DESQVIEW ilk?
DE>
DE>Howdy. Thanks for your interest in OMNIVIEW. Here is a stock blurb, please
DE>me know if it doesn't answer your questions, OK?

Dennis,

First, let me thank you for taking the time to send these two
messages. I'll need a little time to digest everything. It sounds
like just the product that I'm looking for.

Jeff
---
 ■ EZ 1.30 ■

Date: 08-01-90 (09:47)              Number: 518 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 517
From: DENNIS EDWARDS                  Read: 08-01-90 (11:58)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│...two messages. I'll need a little time to digest everything. It sounds
│like just the product that I'm looking for.

OK.
Let me know if you have new questions. I'll do my best to answer them.
---
 ■ EZ 1.30 ■

Date: 08-01-90 (09:47)              Number: 519 / 572 (Echo)
  To: RANDY NOSEWORTHY              Refer#: 510
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

...I only have 512k and the BBS that I run will want 250k and
│then there are the doors... I can more than likely get away with about
│310-320k for one node... I am just full of questions... I've looked at
│Double Dos, and it is quite Chunky, and I've also seen Desqview, but I
│don't think that Desqview will run on an XT.... I've thought about
│going to one meg, and use of a Ram drive to speed things up, but I
│still don't know what type of multitasker would work right, if I were
│to go multi-node... Umm.... That is all that I can think of at the
│moment.... :)

You need to keep both nodes in memory at the same time on anything less than a
386. OMNIVIEW will eat about 60K without LIM 4.0 hardware and about 15K when
loaded into high memory (EMS/XMS). While the upgrade to 640K would certainly
be helpful, you won't get any help (at least from a multitasking perspective)
from the extra 384K. In short, you can expect to have about 500-540K of RAM
to split between the two nodes if you upgrade your system to 640K.
---
 ■ EZ 1.30 ■

Date: 08-01-90 (14:58)              Number: 520 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 518
From: JEFFERY FOY                     Read: 08-02-90 (15:35)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>OK.
DE>Let me know if you have new questions. I'll do my best to answer them.

Only have one question - what happened to the 2nd message? It
didn't quite make it here.

Jeff
---
 ■ EZ 1.30 ■

Date: 08-02-90 (07:02)              Number: 521 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 520
From: RICK KUNZ                       Read: 08-02-90 (15:03)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>  To: DENNIS EDWARDS                Refer#: 518
>
>Only have one question - what happened to the 2nd message? It
>didn't quite make it here.

Hmm... if it was an exact duplicate of an earlier msg, the software
probably purged it. Dennis, if you upload the "stock" answer msg,
probably need to vary something in the header a bit. I use dots after
the subject when this is a known occurrence.

Date: 08-02-90 (16:40)              Number: 522 / 572 (Echo)
  To: RANDY NOSEWORTHY              Refer#: 510
From: TIM FARLEY                      Read: NO
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RN>Jeff, I've got some qestions, how fast is your XT, and also, is
RN>there any slowdown of the BBS due to the fact that it is running
RN>two nodes. Also how much memory are you useing ect.... I've got
RN>an IBM mother board on my XT with a Vic 20 chip, so I'm running
RN>at about 5.33... ( Whoa! what speed! ) I only have 512k and the
RN>BBS that I run will want 250k and then there are the doors...

We were running on a 286 and now we are running on a 386.  On the
10-Mhz 286, there was noticeable slowing, I could imagine it
could get a bit ugly on an XT at 5.33.

Obviously on a 386 there are neat memory tricks that can be
played, but even on an XT you can do one neat thing that will
help out memory wise.  This is what we did on our 286 to load two
nodes of PCBoard/Prodoor:

Get an EMS 4.0 *HARDWARE* compatible memory board, and use either
the software that comes with the board, or other software such as
QRAM from Quarterdeck to cause the board to "backfill" your 512K
of memory to 640K, and *beyond*.  We used 64K of the EMS memory
to fill in between the 640K boundary and the video card, which
left plenty of memory for the two 300K tasks.

Also, if you have a hardware compatible EMS board, you can run
the OMNIHIGH version of OmniView, which loads 48K of it self "out
in the boonies" of RAM so it doesn't take as much space in the
precious 640K (or 704K if you backfill) area.

The only board that I have personally used that I can personally
guarantee is 100% hardware compatible with EMS 4.0 is the AST
Rampage 286.  I am sure there are others, though, perhaps Dennis
has a list.

RN>310-320k for one node... I am just full of questions... I've
RN>looked at Double Dos, and it is quite Chunky, and I've also seen
RN>Desqview, but I don't think that Desqview will run on an XT....

If you are this tight on RAM, OmniView is a *much* better
solution than DesqView.  OV is much stingier with RAM than DV.

--Tim Farley

Date: 08-02-90 (16:40)              Number: 523 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: TIM FARLEY                      Read: HAS REPLIES
Subj: comm port update              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis and Rick, in particular, this is to update you on an old
message thread here.

A while back I posted some messages regarding high speed comm
port usage under OmniView.  We were having some lockup problems
on our 10 Mhz 286 system when I installed 16550 UARTS on the
system to handle the communications load.  (We run a 2-node
PCBoard under OmniView).

Well, we just upgraded the BBS to a 20 Mhz 386 system, and the
lockups that used to occur once in a blue moon started occurring
every 15 minutes!  The system would just go crazy, unless I took
out the 16550's and put in old-style 8250 UARTS on each comm
port.  We had carried over the same comm port card that was in
the 10 Mhz system.

I went crazy trying to diagnose this problem, changing CPU
speeds, swapping chips, etc, etc, etc.  No luck.

Finally, it was suggested that I try another comm port board.
Guess what?  The problem went away.

Apparently, the IOSA dual serial port card that we were using
simply cannot handle two 16550 UART's running on it
simultaneously, *especially* at high CPU speeds.  This problem
would only occur intermittently on a 10 Mhz 286, but on a 20 Mhz
386, it would come up immediately.

This was an odd and unexpected conclusion, considering this comm
port card came to us *inside* a 20 Mhz 386 system!

Switching to a Twincom A.2 serial card sold by SIIG completely
solved the problem.

The IOSA card seems to work perfectly fine at lower speeds, or
even at high bus speeds with 8250 UARTs.  Just don't try to use
it with 16550 UARTs.

--Tim Farley

Date: 08-02-90 (18:22)              Number: 524 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 521
From: JEFFERY FOY                     Read: 08-03-90 (07:06)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

RK>>  To: DENNIS EDWARDS                Refer#: 518
RK>>
RK>>Only have one question - what happened to the 2nd message? It
RK>>didn't quite make it here.
RK>
RK>Hmm... if it was an exact duplicate of an earlier msg, the software
RK>probably purged it. Dennis, if you upload the "stock" answer msg,
RK>probably need to vary something in the header a bit. I use dots after
RK>the subject when this is a known occurrence.

Thanks for that, Rick.

Jeff
---
 ■ EZ 1.30 ■

Date: 08-02-90 (19:03)              Number: 525 / 572 (Echo)
  To: MIKE STROCK                   Refer#: NONE
From: RANDY NOSEWORTHY                Read: 08-03-90 (06:32)
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks Juff... I am still full of un-related (Well sort of Questuions).
The speed-up board that you run, does it help that much, or will should
I just wait, and get a faster system with the $$...
Last night I tried to help a friend set-up a Multi-node Searchlight
BBS, and he has windows... all seems to work well, but Windows 3.0
wants even more memory... he says that he has 2 megs of ram, and his
system is an older 386. He says that windows will only give him about
500k to use for the BBS Systems... from the sound of it, Omniveiw or
Desqview would work better... How much is Omniview?

  Randy


 -> RelayMail : I'm just trying out RelayMail-It's not registered yet.

PCRelay:CALSTAR -> #436 INTELEC + msgs Copyright 1990 by author.

Date: 08-02-90 (00:59)              Number: 526 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: JOHN STEPHENS                   Read: (N/A)
Subj: OMNIVIEW/386                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

I will be soon moving up from a 386/20, to a 396/33 MHz.

Want to know if, OmniView will do a better job (as in speed) for 2 to 4
megs of memory. (most probable, 4 megs)  Want fastest access speed
possible to run 2 nodes of GAP BBS.

I heard DESQVIEW is the ONLY way to go with 386 computers. True? Not?

Information would be appricated!
Thanks,
-- John

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS [phone] HST GAP v 4.4 ■

Date: 08-03-90 (07:04)              Number: 527 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 523
From: RICK KUNZ                       Read: 08-31-90 (15:30)
Subj: COMM PORT UPDATE              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Switching to a Twincom A.2 serial card sold by SIIG completely
>solved the problem.
>
>The IOSA card seems to work perfectly fine at lower speeds, or
>even at high bus speeds with 8250 UARTs.  Just don't try to use
>it with 16550 UARTs.

 Interesting result of all the tinkering, Tim! Glad you finally
pinpointed the source of the problem; perhaps the other cards were just
a little too "smart" for the buffered UARTs. I've saved your message to
disk for later reference. Thanks for posting!

Date: 08-06-90 (01:06)              Number: 529 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RANDY NOSEWORTHY                Read: 08-07-90 (11:06)
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks.... IT would seem that the only thing that would really be worth
runing a Multinode system is a 386, so it will be some time before I
do it... But I do know others that can use some of this info, and
depending on their situation, software. Thanks for your input.

 Randy

 -> RelayMail : I'm just trying out RelayMail-It's not registered yet.

PCRelay:CALSTAR -> #436 INTELEC + msgs Copyright 1990 by author.

Date: 08-06-90 (14:20)              Number: 530 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 523
From: MARC BROOKS                     Read: 08-31-90 (15:30)
Subj: 16550 CHIPS...                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Howdy,
   I have had much fun with 16550 chips in fast machines until I saw the
following blurb in the DSZ.DOC file that comes with DSZ Zmodem software:

     7.10  Brain Damaged UARTS

     Omen Technology has received reports of problems with buggy 8250
type
     UART integrated circuits in Leading Edge modem boards, serial port
     interfaces, and computers.  The defective chip logic affects high
     performance software.  Replacing the buggy chip with a newer chip
(16450
     or NS16550AN) corrects the problem.

   I immediatly replaced my simple 16550 (no AN) with a 16550AN and thre
problems went away!  Also, steer clear of Western Digital 16550's.

                                    Good luck,
                                       Marc

Date: 08-07-90 (00:54)              Number: 532 / 572 (Echo)
  To: TIM FARLEY                    Refer#: NONE
From: RANDY NOSEWORTHY                Read: 08-31-90 (15:30)
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thnanks! I think that you've helped me sort this stuff out. One day, I
will be runing two nodes and/or running on a 286 or better, but
currently I have alot of other priorites to take care of. I really
appreciate your input. I will let my friends know about Omniview, and
keep it in mind when it comes time for people that want to run
multinode BBS'S ect.

          Randy


 -> RelayMail : I'm just trying out RelayMail-It's not registered yet.

PCRelay:CALSTAR -> #436 INTELEC + msgs Copyright 1990 by author.

Date: 08-07-90 (11:07)              Number: 533 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: 520
From: DENNIS EDWARDS                  Read: 08-07-90 (14:36)
Subj: WE'RE HERE                    Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>OK.
│Only have one question - what happened to the 2nd message? It
│didn't quite make it here.

Sorry, I don't know. I'll try again.
---
 ■ EZ 1.30 ■

Date: 08-07-90 (11:07)              Number: 535 / 572 (Echo)
  To: JEFFERY FOY                   Refer#: NONE
From: DENNIS EDWARDS                  Read: 08-08-90 (15:30)
Subj: WE'RE HERE ...                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

--- OMNIVIEW 4.13 Advertisement ---

OMNIVIEW (formerly TASKVIEW) is a preemptive multitasker for DOS
programs; this differentiates it from Microsoft Windows, Software
Carousel and others which do not provide true multitasking. You
CAN achieve true multitasking with Microsoft windows by running
multiple Windows '286 applications inside of OMNIVEW.

Unlike Quartedeck's DESQView, each OMNIVIEW process is a full
screen application - this makes OMNIVIEW both smaller and faster;
A very important consideration when running concurrent real time
applications (such as high speed communication programs or
industrial control systems) or when relying on memory hungry
device drivers and TSRs. Any TopView/DESQView aware application
will run as expected.

In contrast to VM/386, OMNIVIEW does not utilize (nor impose the
overhead of) the multiple '386 virtual 8086 modes. Each process
operates in a single virtual 8086 address space. All device
drivers and TSRs loaded before OMNIVIEW are global to all
processes.

The increasingly popular "dos extenders" may be fully utilized
inside any OMNIVIEW partion, allowing multiple concurrent
multi-megabyte applications.  While OMNIVIEW is compatible with
Quarterdeck's QEMM and other virtual control programs, we
recommend Qualitas' 386^MAX ($49.95) to get the maximum benefit
of OMNIVIEW on '386 systems; the professional version of this
program ($100) will also load device drivers into high memory,
maximizing the space available to run other programs.

SysOps quilify for a 35% discount off OMNIVIEW's $79.95 retail
price.

OMNIVIEW's features include:

-- As many as ten concurrently operating programs on a single
   machine.
-- Runs on all PC/AT/PS/2 machiness from 8088 to 80486 based
   systems.
-- True multitasking with dynamically configurable time slice
   duration (127 levels) and relative process priorities (15
   levels).
-- Utilizes LIM 3.2, 4.0 and EEMS memory.
-- TSR's loaded before OMNIVIEW can be accessed by all processes.
-- TSR's loaded inside partitions act just as any other program,
   to remove them just kill the partition.
-- Supports all standard video adapters in all modes.
-- Loads in as little as 9K of conventional memory.
-- INCREASES memory available to run DOS applications by over 80K
   on some systems.
-- Keyboard macros and the ability to "cut and paste" among
   applications.
-- Easy to use menu interface.
-- Command line interface with a powerful collection of utility
   programs allows experienced users maximum flexibility.
-- Free technical support and much more.

The OMNIVIEW Application Programmer's Interface (OAPI), available
for the asking, has supported C, ASM and Turbo Pascal programmers
since 1986.  All OAPI applications have the ability to:

-- Create and eliminate sibling processes.
-- Suspend, activate and control sibling processes.
-- Send keystrokes to programs running in other partitions.
-- Send and receive various message objects.
-- Perform time sequenced, background events.
-- Establish shared data areas.
-- Create "invisible" customized user interfaces for integrated
   multitasking applications.
-- and much more.

Mailing Address:

Sunny Hill Software
POB 55278
Seattle, WA 98155-5278
FAX:      [phone] - Be sure to SPECIFICALLY ADDRESS all FAX
        messages to Sunny Hill Software.
VOICE:  [phone] - USA and Canada (including WA state).
BBS:    [phone]: Poverty Rock BBS
---
 ■ EZ 1.30 ■

Date: 08-07-90 (22:25)              Number: 536 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 535
From: RICK KUNZ                       Read: 08-10-90 (05:36)
Subj: WE'RE HERE ...                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Dennis: Note my 3 lil dots  in the subject on the msg I'm replying to;
those help keep PCRELAY from deleting a second msg with the same CRC in
the header, as a duplicate. Also, I changed Poverty Rock's phone number
in the msg to the new node 1 number, 206-367-2595; you still had the old
one in there and it is long gone.

Date: 08-10-90 (05:36)              Number: 537 / 572 (Echo)
  To: RANDY NOSEWORTHY              Refer#: 525
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│... He says that windows will only give him about
│500k to use for the BBS Systems... from the sound of it, Omniveiw or
│Desqview would work better... How much is Omniview?

$79.95.  Sysops get 35% discount - just give us the working BBS number when
you call [phone].
---
 ■ EZ 1.30 ■

Date: 08-10-90 (05:36)              Number: 538 / 572 (Echo)
  To: RANDY NOSEWORTHY              Refer#: 529
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVEIW WITH A BBS           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Thanks.... IT would seem that the only thing that would really be worth
│runing a Multinode system is a 386, so it will be some time before I
│do it... But I do know others that can use some of this info, and
│depending on their situation, software. Thanks for your input.

Well it is possible to run multiple concurrent BBS nodes - even on 8088, but
you have to be using very tight software. It is _certainly_ much easier to do
multitasking on a 386. Look forward to hearing from you when you get the new
box. Take care.

---
 ■ EZ 1.30 ■

Date: 08-10-90 (05:36)              Number: 539 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 523
From: DENNIS EDWARDS                  Read: 08-31-90 (15:30)
Subj: comm port update              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│A while back I posted some messages regarding high speed comm
│port usage under OmniView....
│This was an odd and unexpected conclusion, considering this comm
│port card came to us *inside* a 20 Mhz 386 system!

Odd indeed. Lots 'o people (including - maybe especially - me) seem to be
getting so used to dealing with software problems that we forget to check the
stuff that probably would have been obvious to us a couple years ago. When
things were simple: ah, this flaky LSTTL stuff - cap gets a little weak and
it just loses the load...

Thanks for the update, Tim. Glad you found the problem.

---
 ■ EZ 1.30 ■

Date: 08-10-90 (05:36)              Number: 540 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 526
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW/386                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I will be soon moving up from a 386/20, to a 396/33 MHz.
│Want to know if, OmniView will do a better job (as in speed) for 2 to 4
│megs of memory. (most probable, 4 megs)  Want fastest access speed
│possible to run 2 nodes of GAP BBS.
│I heard DESQVIEW is the ONLY way to go with 386 computers. True? Not?

Well DV ain't the only way to go, fer sure. The most obvious difference
between OMNIVIEW and it is that all (10 max) OV procs are full screen.
OMNIVIEW is also a bit smaller and, according to user reports - runs multinode
BBS systems with a little quicker throughput (10-15%). It is also fairly
common to run it on a Lantastic server (or client).

If you use the menu (versus command line) interface you'll spend about 100K
total on OMNIVIEW though only about 10-15K will typically be in the low DOS
RAM area (TPA - lower 640..704K).  So you should easily get two 550K nodes -
just make sure that they use different ports and that the cards are strapped
to different Interrupt Request Lines (IRQs).

You will need 386^Max or 386^Mate (our memory manager) to pull this off since
not all the stuff we need to be able to do is documented in other products.



---
 ■ EZ 1.30 ■

Date: 08-08-90 (23:48)              Number: 542 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RON HOSSACK                     Read: 08-13-90 (06:23)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hi...ordered Omniview a few weeks ago and was told that the new
version would be released shortly.  How much longer must I droolin
anticipation < smile >

-> MegaMail v2.00 #560:Standing Righteous in the eyes of God

PCRelay:LATENITE -> #406 INTELEC (tm) Network, Freeport, NY
4.10                The Late Show! Riverside, CA 714-359-5624 HST

Date: 08-11-90 (19:05)              Number: 543 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: FRANK GAY                       Read: (N/A)
Subj: OMNI QUESTIONS                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Hello All.
 I have been reading through the Omniview messages with great interest..
and while reading, I had a couple of questions come to mind that the
messages did not seem to answer.

1. If Omniview is multitasking, how does one switch to another
partition? I ask this because the message threads seem to indicate that
Omniview is a command line program. That is, one must drop out of the
application and issue a command that will get them to another partition.

2. If Omniview is "switchable" without exiting to DOS what keys are used
to do so? I ask this because I am a user of 386max and Desqview and have
found that some of the keys (especially in Desqview) conflicted with
some of my applications, and I found that I could reassign them. I would
be curious to know what key(s) are used to switch to another partition
and if it is reassignable?

Thanks,
    Frank
---
 ■ R105J:The Classic BBS  (413)-782-3284

PCRelay:INTELEC -> #402 Intelec (tm) Network, Freeport, NY
4.10ß15            PCRelay/Rnet/Qnet/NetMail and the best users!

Date: 08-11-90 (05:32)              Number: 544 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: RON HOSSACK                     Read: (N/A)
Subj: OMNIVIEW & SPITFIRE           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Has any Spitfire sysop used Omniview?  If so, would be interested in
what you did to set it up and any problems encountered

->MegaMail v2.00 #560:Love at first CONNECT....errrr, Byte

PCRelay:LATENITE -> #406 INTELEC (tm) Network, Freeport, NY
4.10                The Late Show! Riverside, CA 714-359-5624 HST

Date: 08-13-90 (06:24)              Number: 545 / 572 (Echo)
  To: RICK KUNZ                     Refer#: 536
From: DENNIS EDWARDS                  Read: 08-13-90 (06:57)
Subj: WE'RE HERE ...                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Dennis: Note my 3 lil dots  in the subject on the msg I'm replying to;
│those help keep PCRELAY from deleting a second msg with the same CRC
│in the header, as a duplicate.
 ^^^^^^^^^^^^^

Ahhh, OK. I thought it was checking the _message_ and knew that to be
different (if not unique)...But Now I See.


>Also, I changed Poverty Rock's phone number
│in the msg to the new node 1 number, 206-367-2595; you still had the old
│one in there and it is long gone.

Sorry. I know I changed that once but I must have got a tick behind somehow.
Thanks for taking care of me, again, there Uncle Rick.


---
 ■ EZ 1.30 ■

Date: 08-13-90 (06:57)              Number: 546 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 545
From: RICK KUNZ                       Read: 08-14-90 (17:17)
Subj: WE'RE HERE ...                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>Sorry. I know I changed that once but I must have got a tick behind som
>Thanks for taking care of me, again, there Uncle Rick.

 Yer quite welcome; I appreciate yours and Sunny Hill's participation
here!

Date: 08-14-90 (17:18)              Number: 547 / 572 (Echo)
  To: FRANK GAY                     Refer#: 543
From: DENNIS EDWARDS                  Read: NO
Subj: OMNI QUESTIONS                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Hello All.
│ I have been reading through the Omniview messages with great interest..
│and while reading, I had a couple of questions come to mind that the
│messages did not seem to answer.
│
│1. If Omniview is multitasking, how does one switch to another
│partition? I ask this because the message threads seem to indicate that
│Omniview is a command line program. That is, one must drop out of the
│application and issue a command that will get them to another partition.

OMNIVIEW is not command line driven in the way of some modal editors or a
spread sheet; rather it allows you to run utility programs from a DOS command
line (and .BAT files) to control/modify things. One of the supplied utilities
is called SWITCHTO and takes a "console number" as an argument - this can be
used to bring a process to the foreground, but it is not the only way that
this can be done.

A console number is, generally, the number embossed on the top of the "hot
key" used to switch between one partition and another. Console numbers are
assigned, in increasing order, to partitions as they are created. If a
partition dies and leaves a hole in the console number list, that vacant
number will be assigned to the next process created. There can be as many as
ten partitions active at one time. The "1" key represents the first partition,
"2" the second, and the "0" key represents the tenth partition.

A typical OMNIVIEW command line setup will have a DOS partition that is
dedicated to running utilities - including those that come with OMNIVIEW. This
DOS control partition would be brought to the foreground by activating its
console number "hot key" in order to "activate" the command line.

There is also a menu driven shell that can be used in place of the command
line utilities. This is simply an OMNIVIEW specific program that is run in the
first partition.

│2. If Omniview is "switchable" without exiting to DOS what keys are used
│to do so? I ask this because I am a user of 386max and Desqview and have
│found that some of the keys (especially in Desqview) conflicted with
│some of my applications, and I found that I could reassign them. I would
│be curious to know what key(s) are used to switch to another partition
│and if it is reassignable?

By default the "hot keys" are <Ctrl><LShift><Kn> where <Kn> is the key on the
number pad that represents the desired process' console number. The numbers on
the top of the QWERTY portion of the keyboard may also be used. The shift
state for the "switch to hot keys" can be assigned to any combination of
<Alt>, <Ctrl>, <LShift> and <RShift> (the left and right Alt and Ctrl states
are not considered unique). The "hot key" assignments are changed by running
the menu driven OVSETUP program.



---
 ■ EZ 1.30 ■

Date: 08-14-90 (17:18)              Number: 548 / 572 (Echo)
  To: RON HOSSACK                   Refer#: 542
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│Hi...ordered Omniview a few weeks ago and was told that the new
│version would be released shortly.  How much longer must I droolin
│anticipation < smile >

Uggh. The printers should get the manual this week. A couple things showed up
that we needed to fix. I apologise for the delay.
---
 ■ EZ 1.30 ■

Date: 08-12-90 (18:27)              Number: 549 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JOHN STEPHENS                   Read: 08-23-90 (10:42)
Subj: OMNIVIEW/386                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

>>You will need 386^Max or 386^Mate (our memory manager) to pull this
>>not all the stuff we need to be able to do is documented in other pr

So, If I purchase OmniView, and 386^Max/^Mate, how much would the
total come to?

-> MegaMail v2.00 #0:My BBS is open 24 hours, Eastern Time Only.

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS [phone] HST GAP v 4.4 ■

Date: 08-17-90 (12:59)              Number: 550 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RON HOSSACK                     Read: 08-23-90 (10:42)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE> │Hi...ordered Omniview a few weeks ago and was told that the new
DE> │version would be released shortly.  How much longer mut I droool
DE> │anticipation < smile >
DE>
DE> Uggh. The printers should get the manual this week. A couple thing
DE> that we neded to fiix. I apologise for the delay.

No problem......my new BBS software hasn't arrived yet, but when it
does.......

-> MeaMail v2.00 #560:Standing Righteous in the eyes of God

PCRelay:LATENITE -> #406 INTELEC (tm) Network, Freeport, NY
4.10                The Late Show! Riverside, CA 714-359-5624 HST

Date: 08-19-90 (09:54)              Number: 551 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: TODD STEPHENS                   Read: (N/A)
Subj: WE HAVE IT NOW!!              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


========================================================================
==============The DATA BBS is now carrying this conference!=============
========================================================================

                          -=[ [phone] ]=-

NET/Mail : INTELEC (tm)  ---  The Data BBS   -=[ (615) - 531-6316 ]=-

PCRelay:INTELEC -> #402 Intelec (tm) Network
4.10               Intelec Host BBS 516 867-4446/7 HAY -4448 HST

Date: 08-24-90 (17:05)              Number: 552 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 549
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW/386                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│>>You will need 386^Max or 386^Mate (our memory manager) to pull this
│>>not all the stuff we need to be able to do is documented in other pr
│So, If I purchase OmniView, and 386^Max/^Mate, how much would the
│total come to?

 $119.95 for OMNIVIEW 386.
 $79.95 for OMNIVIEW alone.
 $130 (I think) for 386^MAX pro/5.0

---
 ■ EZ 1.30 ■

Date: 08-24-90 (17:05)              Number: 553 / 572 (Echo)
  To: RON HOSSACK                   Refer#: 550
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE> │Hi...ordered Omniview a few weeks ago and was told that the new
│DE> Uggh. The printers should get the manual this week. A couple thing
│DE> that we neded to fiix. I apologise for the delay.
│No problem......my new BBS software hasn't arrived yet, but when it
│does.......

OK.
---
 ■ EZ 1.30 ■

Date: 08-24-90 (17:05)              Number: 554 / 572 (Echo)
  To: TODD STEPHENS                 Refer#: 551
From: DENNIS EDWARDS                  Read: NO
Subj: WE HAVE IT NOW!!              Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│========================================================================
│==============The DATA BBS is now carrying this conference!=============
│========================================================================
│
│                          -=[ [phone] ]=-
│
│NET/Mail : INTELEC (tm)  ---  The Data BBS   -=[ (615) - 531-6316 ]=-
│
│PCRelay:INTELEC -> #402 Intelec (tm) Network
│4.10               Intelec Host BBS 516 867-4446/7 HAY -4448 HST

Welcome. And thanks for picking up the conference.

Dennis Edwards
OMNIVIEW conference host


---
 ■ EZ 1.30 ■

Date: 08-22-90 (10:37)              Number: 555 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: PAUL GODDU                      Read: (N/A)
Subj: HELLO                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

The Aldenville Station Pcb Bbs is carrying this conference.

                              T.T.F.N.
                      =========Paul G.=========
---
 ■ RNet 1.04U: ■INTELEC >The Aldenville Station ■ Chic. ■ MA ■ [phone]

PCRelay:INTELEC -> #402 Intelec (tm) Network
4.10               Intelec Host BBS 516 867-4446/7 HAY -4448 HST

Date: 08-27-90 (22:03)              Number: 556 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RON HOSSACK                     Read: 08-29-90 (08:36)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE> │DE> │Hi...ordered Omniview a few weeks ago and was told that the
DE> │DE> Uggh. The printers should get the manual this wee. AA couple
DE> │DE> that we neded to fiix. I apologise for the delay.
DE> │No problem......my new BBS software hasn't arrived yt, buut when
DE> │does.......

Installed my multi-node software last night.  Is the printer getting
the ink on the paper yet? < mile >

-> MegaMail v2.00 #560:SEEK ERROR....SEEK ERROR......OH NO!!!

PCRelay:LATENITE -> #406 INTELEC (tm) Network, Freeport, NY
4.10                The Late Show! Riverside, CA 714-359-5624 HST

Date: 08-27-90 (02:35)              Number: 557 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: JOHN STEPHENS                   Read: 09-06-90 (12:46)
Subj: OMNIVIEW/386                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

=> $119.95 for OMNIVIEW 386.
=> $79.95 for OMNIVIEW alone.
=> $130 (I think) for 386^MAX pro/5.0

So, what is the difference between the three, I know OmniView,
alone is for 286 and below.  OmniView 386 is for 386's, but, whats
the other?

-> MegaMail v2.00 #0:Intelec (tm) Network - Worlds Fst'st Growing Net

PCRelay:PHOENIX -> Intelec (tm) Free Message Exchange
                   ■ PHOENIX BBS [phone] HST GAP v 4.4 ■

Date: 08-30-90 (09:08)              Number: 558 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 516
From: TOM OPPENHEIMER                 Read: 09-06-90 (12:46)
Subj: SETTING UP A WILDCAT BBS      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

Thanks for all the info!!  Since I last was here I've deceided to scrap
the 286 mother board and install a 386SX. I was able to borrow my
computer from work (a 386SX) and setup the board using "a competitors"
multitasking software. I'm waiting for the newer version of OMNIVIEW
which I have ordered several weeks ago. Hopefully it'll arrive soon. At
the time I didn't order the 386 version so I'm sure I'll be going back
to pick up that version.
I will digest the info you've provided and go from there. Thanks again.

Date: 08-23-90 (23:49)              Number: 559 / 572 (Echo)
  To: LABYRIN                       Refer#: NONE
From: DEREK BACKUS                    Read: NO
Subj: F:A-DIALER.ZIP                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

d
---
 ■ EZ 1.33 ■

NET/Mail : The Labyrinth, Monrovia, CA    [phone]

PCRelay:FORTYTO -> #405 Intelec (tm) SouthWestern Region
4.10               42 BBS III La Crescenta, Ca [phone]

Date: 08-31-90 (18:28)              Number: 560 / 572 (Echo)
  To: MARC BROOKS                   Refer#: 530
From: TIM FARLEY                      Read: NO
Subj: 16550 CHIPS...                Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

MB>   I immediatly replaced my simple 16550 (no AN) with a 16550AN
MB>and thre problems went away!  Also, steer clear of Western
MB>Digital 16550's.

Thanks for the reminder.  I have seen the same advice elsewhere,
too--avoid the 16550's without the "AN" or "AFN" prefix.

As it turns out, we had 16550AN's all along, so it didn't apply
in our case.

--Tim Farley

Date: 08-31-90 (18:28)              Number: 561 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 540
From: TIM FARLEY                      Read: 09-06-90 (12:46)
Subj: 386 Memory managers           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>You will need 386^Max or 386^Mate (our memory manager) to pull this off sin
DE>not all the stuff we need to be able to do is documented in other products.

I was going to ask about that---we're running 386^Max on our
system now, version 4.07.  But we just got QEMM version 5.0 (or
maybe 5.1, don't recall) and I was wondering about the relative
advantages of each.

I gather that between those two, 386^Max would be preferred?


Also, when you talk about OmniView-386, is that a special version
of OV, or just OV bundled with a memory manager (like the way
"the other guys" do it)?

--Tim Farley

Date: 08-31-90 (18:28)              Number: 562 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: 548
From: TIM FARLEY                      Read: 09-06-90 (12:46)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

DE>Uggh. The printers should get the manual this week. A couple
DE>things showed up that we needed to fix. I apologise for the
DE>delay.

Oooh, is there a new manual and/or version imminent?

--Tim Farley

Date: 09-06-90 (12:46)              Number: 563 / 572 (Echo)
  To: PAUL GODDU                    Refer#: 555
From: DENNIS EDWARDS                  Read: NO
Subj: HELLO                         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│The Aldenville Station Pcb Bbs is carrying this conference.
│                              T.T.F.N.

Welcome. Hope you enjoy the conference.
---
 ■ EZ 1.30 ■

Date: 09-06-90 (12:46)              Number: 564 / 572 (Echo)
  To: RON HOSSACK                   Refer#: 556
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE> │DE> │Hi...ordered Omniview a few weeks ago and was told that the
│Installed my multi-node software last night.  Is the printer getting
│the ink on the paper yet? < mile >

Uhhh, yeah, should be.
---
 ■ EZ 1.30 ■

Date: 09-06-90 (16:32)              Number: 565 / 572 (Echo)
  To: JOHN STEPHENS                 Refer#: 557
From: DENNIS EDWARDS                  Read: NO
Subj: OMNIVIEW/386                  Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│=> $119.95 for OMNIVIEW 386.
│=> $79.95 for OMNIVIEW alone.
│=> $130 (I think) for 386^MAX pro/5.0
│
│So, what is the difference between the three, I know OmniView,
│alone is for 286 and below.  OmniView 386 is for 386's, but, whats
│the other?

Yeah, OMNIVIEW is the multitasking software and utilities. The 386 version
has some additional programs, including a memory manager, that make the
386 more useful for multitasking.  386^Max is a stand alone memory management
software product.
---
 ■ EZ 1.30 ■

Date: 09-06-90 (16:32)              Number: 566 / 572 (Echo)
  To: TOM OPPENHEIMER               Refer#: 558
From: DENNIS EDWARDS                  Read: NO
Subj: SETTING UP A WILDCAT BBS      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│I will digest the info you've provided and go from there. Thanks again.

Glad you found it useful and congrats on the 386.  The upgrade is done. See
my subsequent post for details.

---
 ■ EZ 1.30 ■

Date: 09-06-90 (16:32)              Number: 567 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 561
From: DENNIS EDWARDS                  Read: 09-07-90 (15:55)
Subj: 386 Memory managers           Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>You will need 386^Max or 386^Mate (our memory manager) to pull this off si
│I was going to ask about that---we're running 386^Max on our
│system now, version 4.07.  But we just got QEMM version 5.0 (or
│maybe 5.1, don't recall) and I was wondering about the relative
│advantages of each.
│I gather that between those two, 386^Max would be preferred?

Yeah. Prior to 5.0, that is. If you order an update from Qualitas make
sure they have the problems with their SCREEN parameter fixed - assuming
you want it to run OMNIVIEW, anyway.

│Also, when you talk about OmniView-386, is that a special version
│of OV, or just OV bundled with a memory manager (like the way
│"the other guys" do it)?

Yeah it is a bundled memory manager and a couple support programs.
See my subsequent post for a description.
---
 ■ EZ 1.30 ■

Date: 09-06-90 (16:32)              Number: 568 / 572 (Echo)
  To: TIM FARLEY                    Refer#: 562
From: DENNIS EDWARDS                  Read: 09-07-90 (15:55)
Subj: OMNIVIEW                      Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>Uggh. The printers should get the manual this week. A couple
│
│Oooh, is there a new manual and/or version imminent?

Yupper. :-))
---
 ■ EZ 1.30 ■

Date: 09-06-90 (16:32)              Number: 569 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: NEW OMNIVIEW VERSION!         Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

OMNIVIEW 4.20 is here!

It has been, admittedly, a while since you've seen any updates from us but
this one should make most of you happy. Probably the biggest news is that we
now offer 386-Mate, a very capable 386 memory manager, in combination with the
OMNIVIEW multitasker and all the utility programs. This powerful collection,
called OMNIVIEW 386 lists for $119.95. The OMNIVIEW multitasking software and
utilities lists for $79.95.

Our traditional 35% Sysop discounts apply to inital purchase prices, just give
us the number of your working BBS. For upgrade pricing and/or to place an
order, call [phone]. Visa and MasterCard accepted.

Here is a list of some changes from version 4.13:

386-Mate: NEW!
    Supports any combination of EMS, conventional, high DOS and extended
    memory.
    LIM 4.0 EMS support.
    XMS support.
    Virtual Control Program Interface (VCPI) supported.
    "Topfills" and "Backfills" DOS memory (Can increase DOS memory up to
    704K on MDA/Hercules/CGA systems giving you multiple 600+K OMNIVIEW
    processes).
    TSRs can be loaded high.
    Device drivers can be loaded high.
    High DOS status display available.
    Interrupt handlers can be swappable.
    Hardware virtual screen for text and CGA graphics.
    Simple menu driven configuartion of first megabyte.

INSTALL: NEW!
    Menu driven interface.
    Configurable installation options.
    Built in editor (with help) for changing CONFIG.SYS and AUTOEXEC.BAT,
    reading the READ.ME file.
    Option to reboot on exit.

MANUAL:
    Expanded and updated and revised.
    Lots more installation/configuration information.
    Scheculing algorithm explained in more detail.
    Command line utility options explained in terms of menu options.
    --OVUTILS.DOC file describes all utilities not described in manual
      includes examples.
    --Example .BAT files and Application Notes on disk cover commonly
      asked questions.

OMNIVIEW:
    Improved EMS support (used to act like a LIM 3.2 driver, now it acts
        like a LIM 4.0 driver on LIM 3.2 hardware so programs that
        didn't use EMS at all before now will use EMS inside a partition)
    Windows 3.0 supported.
    Improved program exit handler.
    Improved support for debuggers and integrated programming environments
    Improved NUL device support.
    Improved handling of enhanced keyboard (Ctrl-Alt-GreyDel doesn't reset
        the whole machine now but just closes a partition).
    Improved DOS command line editor
    New command line switch (/B) supports screen reading software by
        sending some foreground process video output to BIOS
        (this is for blind/low vision folks).
    User written OMNIVIEW device drivers support. You can now get
        configuration information when a new process is created
        (passed with the USR_ALLOC signal in DS:DX as part of the
        "DOS" device parameter string). I'll post more on this
        later - it's implications are significant.
    Virtual cursors supported (programs that program the cursor position
        registers directly don't move the foreground cursor around)
    Improved mouse support
    Improved DOS Critical Error handling (virtual screens turned off on
        first BIOS call so "Abort, Retry..." prompt from background
        program now shows up somewhere on foreground display when
        a Critical Error occures in a background partition).

OPEN and SPAWN:
    Both now support a range of allowable parition sizes as does the
    shell. Defaults to all available memory if no /M:nnn-xxx argument
    is given. Exact parition sizes specified by /M:nnn.

XSHELL and OMNIHIGH:
    Now search their own directory and all directories in the current
    DOS alternate path list for the programs they load high. OMNIHIGH
    sets ERRORLEVEL to OMNIVIEW exit code.

OVSETUP:
    Now has options for loading OMNIVIEW in high memory and including
    messages telling why OMNIVIEW exited.

OVSHELL.COM
    Supports InColor card.
    Updated help files.



     * * * C O N T I N U E D   T O   N E X T   M E S S A G E * * *
---
 ■ EZ 1.30 ■

Date: 09-06-90 (16:32)              Number: 570 / 572 (Echo)
  To: ALL                           Refer#: NONE
From: DENNIS EDWARDS                  Read: (N/A)
Subj: NEW OMNIVIEW VERSION! (2)     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)


        New stuff in OMNIVIEW 4.20, continued...

BEEPER:
    NEW: A resident scheduling monitor utility. This version can be turned
    on/off with a hot key.

CONCURE:
    NEW: This "expert system" for evaluating your system's multitasking
    capability is now distributed as part of the regular package.

ELSTRING:
    NEW: Converts DOS ERRORLEVEL to an environment string. Even works
    outside of batch files if your shell is COMMAND.COM (or a clone).

EXEINFO:
    NEW: Reports minimum partition size needed for an .EXE file.

FASTPRN:
    NEW: Greatly improves print speed for some programs.

PRINTSPL:
    NEW: a simple print spooler program.

SENDKEYS:
    Now takes input from either a text file or a Super Macs macro file.
    Indiviual macros or the whole SMACS file can be played back.
    Several new printf() type formatting options as well as playback
    delays and environment variable substitution. Comments supported
    in text files.

SMACS:
    Bug fixed in macro editor.

WAITKEYS:
    Now takes "prompt" input from files so menus can be easily
    displayed. Supports printf() type "escape sequences" similar to
    SENDKEYS for the "valid keys" descriptions - so keys like <Enter>,
    <F1>, etc. can now be used. Features a natural language interface
    (NLP) that interprets the "delay" specifications - It is now
    possible to specify things like:
        in 3 minutes    -OR-   on Dec. 31, 1999
    And have it respond correctly (and yes it will wait that long if
    you really want it to).

SHOWKEYS:
    NEW: Displays keystrokes as "escape sequences" that can be used
    by SENDKEYS and WAITKEYS (echo-able to a file).

WHERES:
    NEW: A flexible file find utility.


All in all, this is quite a significant upgrade. While a lot these changes
will be invisible to you (though not necessarily to your applications) the
improvements we've made will guarantee you an efficient, rock-solid
multitasking operating environment for your PC and allow for some additional
capability in the future.

Thanks for taking a look at this notice, we look forward to hearing from
you soon.

---
 ■ EZ 1.30 ■

Date: 09-08-90 (18:47)              Number: 571 / 572 (Echo)
  To: DENNIS EDWARDS                Refer#: NONE
From: RON HOSSACK                     Read: 09-11-90 (04:28)
Subj: New Omniview Version! (2)     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

│DE>         New stuff in OMNIVIEW 4.20, continued...                │
╘════════════════════════════════════════════════════════════════════╛

Dennis...I've ordered this a few months ago...how soon before shipping?

-> MegaMail v2.01 #560:Spitfire 3.0 just sweeter and sweeter
---
 * SFUTI 3.01 » Solid Rock [phone] 38400-1200 HST

PCRelay:SOLIDRCK -> #0 INTELEC (tm) Network, Freeport, NY
4.10                Solid Rock BBS [phone]  38400-1200 HST

Date: 09-11-90 (07:30)              Number: 572 / 572 (Echo)
  To: RON HOSSACK                   Refer#: 571
From: DENNIS EDWARDS                  Read: NO
Subj: New Omniview Version! (2)     Status: PUBLIC MESSAGE
Conf: OMNIVIEW (6)               Read Type: GENERAL (+)

││DE>         New stuff in OMNIVIEW 4.20, continued...                │
│╘════════════════════════════════════════════════════════════════════╛
│
│Dennis...I've ordered this a few months ago...how soon before shipping?

Everything is done now. Sorry for the delay. Wanted to ship it as right as
we knew about...

Actual shipments are only waiting on initial manual/disk production and should
begin soon.

---
 ■ EZ 1.30 ■